JVM JIT编译采用分层动态策略：先解释执行，再依热度由C1快速优化、C2深度优化；触发依赖方法调用（4500次）和循环回边（10700次）计数器，衰减机制防误判；C1侧重低开销基础优化，C2专注激进长期优化；五级分层（Level 0–4）协同，profiling越深越利于C2但C1性能略降；编译失败可降级至C1或解释执行，全编译（-Xcomp）反而损害性能。
JVM 的 JIT 编译不是“一上来就全编译”，而是按热度动态分层推进：先解释执行，再由 C1 快速优化，最后让 C2 深度优化长期热点代码。它本质是一种运行时决策机制——只对真正高频、稳定执行的代码投入编译资源。
触发编译靠“热度”，不是启动就编译
方法不会一运行就被编译。JVM 通过两个计数器持续监控：
- 方法调用次数，默认达 4500 次（HotSpot 8u）触发 C1 编译；
- 循环回边（如 for、while 循环末尾跳回头部）次数，默认达 10700 次，可能直接触发 C2 编译；
- 计数器每秒衰减 2%（×0.98），避免短期突发调用被误判为长期热点；
- 可通过
-XX:CompileThreshold=10000调整阈值，但需结合压测验证效果。
C1 和 C2 各干各的事，不互相替代
C1 不是“简陋版 C2”，而是定位不同的优化角色：
- C1（Client Compiler）：编译快、开销小，适合响应敏感场景。做方法内联、空值检查消除、基础逃逸分析，但保留大量安全检查（如数组边界校验）；
- C2（Server Compiler）：编译慢、优化激进，专为长期运行服务。支持循环展开、向量化、去虚拟化、标量替换，且能在确认对象不逃逸后直接删掉冗余检查；
- 一个 Spring Boot 应用启动时，
DispatcherServlet.doDispatch这类入口方法通常先被 C1 编译；而业务中持续计算的calculateRiskScore方法，若含大循环且调用稳定，后续会被 C2 接管重编译。
分层编译不是线性升级，而是五级协同
Java 7 起默认启用分层编译（-XX:+TieredCompilation），共 5 层：
立即学习“Java免费学习笔记（深入）”；
- Level 0：纯解释执行，开启性能采样（profiling）；
- Level 1：C1 编译，无 profiling，生成轻量代码（适合 trivial 方法如 getter）；
- Level 2：C1 编译 + 基础 profiling（调用计数、循环回边）；
- Level 3：C1 编译 + 全面 profiling（分支跳转、接收者类型等）；
- Level 4：C2 编译，基于 Level 2/3 收集的 profile 数据做深度优化。
注意：profiling 越多，C1 代码运行越慢（Level 3 比 Level 1 慢约 30%），但为 C2 提供了关键优化依据。
编译失败会降级，不是卡死在某一层
JIT 是带逃生机制的：
- C2 编译失败（例如泛型类型无法推断、内联链过深），会退回到 C1 编译版本；
- 若 C1 也失败或代码行为异常，JVM 可能标记该方法为
made not entrant或made zombie，后续走解释执行； - 强制
-Xcomp全编译反而有害：启动极慢、内存暴涨、缺少运行时 profile 导致优化质量差；-Xint完全禁用 JIT 则会让长期热点逻辑始终慢在解释阶段。
