jit编译器在方法调用次数达4500或循环回边次数达10700时触发c1/c2编译，计数器每秒衰减至98%，并非启动即编译；c1适合快速响应场景，c2适合长期运行的计算密集型逻辑。
Java JIT编译器到底什么时候开始工作？
不是启动就编译，也不是所有代码都会被JIT。JVM默认启用分层编译（-XX:+TieredStopAtLevel=1 可关掉），但真正触发C1或C2编译，取决于方法的执行热度——也就是调用次数和循环回边次数。
常见错误现象：java -Xcomp 强制全程编译，结果启动巨慢、内存暴涨，还可能因缺少运行时信息导致生成低效代码；反过来，-Xint 完全禁用JIT，又会让长期运行的热点逻辑卡在解释执行阶段。
- 方法调用计数器默认阈值是
4500（HotSpot 8u），达到后进入C1编译队列 - 循环回边（back-edge）计数器默认阈值是
10700，用于识别长循环热点，可能直接触发C2编译 - 计数器不是绝对值，会周期性衰减（每秒 *0.98），所以“冷下来”的方法可能退回到解释执行
- 可通过
-XX:CompileThreshold=10000调高阈值，但需配合实际压测验证——调太高，C2迟迟不介入；调太低，编译线程抢资源，反而拖慢吞吐
C1和C2编译器分别适合什么代码？
C1（Client Compiler）快但保守：做基础优化（如方法内联、空值检查消除），生成代码体积小、编译延迟低，适合启动阶段或响应敏感型场景（比如Web API首请求）；C2（Server Compiler）慢但激进：做逃逸分析、循环展开、向量化、去虚拟化，适合长时间稳定运行的计算密集型逻辑。
使用场景差异明显：一个Spring Boot应用刚启动时，org.springframework.web.servlet.DispatcherServlet.doDispatch 这类高频入口方法大概率先被C1编译；而跑着跑着，你业务里那个 calculateRiskScore 方法如果持续被调用+内部有大循环，就会被C2接管重编译。
立即学习“Java免费学习笔记（深入）”；
- C1生成的代码仍含大量安全检查（如数组边界），C2在确认对象逃逸不出方法后，会直接删掉这些检查
- C2能识别
for (int i = 0; i 中的 <code>list.size()不变，将其提至循环外——但前提是它观察到该方法多次执行且list未被修改 - 注意：C2编译失败（比如遇到无法推断的泛型类型）会降级回C1，甚至退化为解释执行，日志里会出现
made not entrant或made zombie
怎么确认某段代码被哪个编译器处理了？
靠日志，不是靠猜。加JVM参数打开编译日志最直接：-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+LogCompilation。其中 PrintCompilation 输出简洁，LogCompilation 生成XML可配合 jitwatch 分析。
典型日志行：12345 100 3 java.lang.String::hashCode (67 bytes) —— 第二列 100 是方法序号，第三列 3 表示C2编译（1=C1, 4=native stub），最后括号里字节数是生成的汇编指令长度。
- 看到同一方法出现两次编译记录（比如先
1后3），说明发生了从C1到C2的“栈上替换”（On-Stack Replacement），即正在执行的循环被热替换为C2版本 - 如果日志里频繁出现
made not entrant，大概率是C2优化过度导致运行时契约被破坏（比如把本该抛NullPointerException的路径优化掉了），需要检查是否用了不安全的反射或动态代理 -
-XX:+PrintGCDetails和编译日志混着看：若GC停顿期间突然冒出大量Compiled method，说明编译线程正抢占CPU，要考虑调低-XX:CICompilerCount
分层编译模式下，哪些配置真会影响线上性能？
分层编译（Tiered Compilation）不是开关，而是一套调度策略：解释执行 → C1编译 → C2编译 → C2深度优化。中间任何一层卡住或跳过，都可能让关键路径始终停留在低效状态。
最容易被忽略的坑是：JDK 8默认开启分层编译，但JDK 17+默认关闭（-XX:-TieredStopAtLevel=1 被移除，改由GraalVM替代）。如果你还在用JDK 8/11，别盲目加 -XX:+UseParallelGC 就以为万事大吉——GC策略和编译调度是两套独立系统，但GC停顿会打断编译线程的采样，间接拉长C2介入时间。
-
-XX:TieredStopAtLevel=1强制只用C1，适合极短生命周期应用（如FaaS函数），但会损失C2的所有高级优化 -
-XX:ReservedCodeCacheSize=256m必须设够——C2生成的代码更大，Cache满会导致编译停止，后续所有热点都fallback到解释执行 - 容器环境要特别注意：
-XX:+UseContainerSupport（JDK 10+）必须开启，否则JVM按宿主机核数算CICompilerCount，在4核容器里起8个编译线程，纯粹内耗
分层编译的复杂点在于，它依赖运行时反馈做决策，而反馈本身受GC、锁竞争、外部IO干扰。想靠几个参数一劳永逸？基本没戏。得盯着 PrintCompilation 日志，结合 jstack 看编译线程是否阻塞，再比对业务指标拐点——这才是真实调试路径。
