分层编译是动态协作机制：第0层解释执行首调方法，第1层C1在约1500次调用后快速编译，第2–4层C2对高频方法深度优化；阈值可调，代码写法与缓存管理影响优化效果。

分层编译不是开关，而是一套动态协作机制：它让解释器扛住启动压力，再由C1和C2编译器按热度梯度接手，最终在冷热代码之间划出清晰的执行边界。

理解三层执行角色分工

分层编译本质是把“谁来执行、何时切换、优化到什么程度”拆解成三个层次：

• 第0层（解释执行）：所有方法首次调用都走这里。不编译、无延迟，但每条字节码都要查表翻译，适合短生命周期或仅执行几次的逻辑
• 第1层（C1编译）：当方法调用次数或循环回边次数达到阈值（默认约1500），C1快速生成带基础优化（如公共子表达式消除、简单内联）的机器码，耗时短、代码体积小
• 第2–4层（C2编译）：持续高频调用后触发，C2做深度优化（逃逸分析、多态内联、循环向量化等），生成高性能但体积更大、编译更久的代码；JVM默认最多支持5层（TieredStopAtLevel=5）

关键阈值与触发条件怎么调

默认阈值对多数服务够用，但若你观察到启动后性能爬升慢、或长稳态仍有未优化热点，可微调：

• -XX:CompileThreshold=10000：提高C1触发门槛，减少早期编译开销，适合启动后流量平稳、热点明确的服务
• -XX:TieredStopAtLevel=1：强制停在C1层，牺牲峰值性能换更可控的内存占用和启动响应，适合边缘设备或函数计算场景
• -XX:+UseCounterDecay：启用计数器衰减，避免历史热点长期霸占编译资源，让新热点有机会上位
• 注意：回边计数器（针对循环）独立于方法调用计数器，对密集循环体影响更大，无需单独设参，但写代码时应避免无意义空循环干扰检测

代码写法如何配合分层节奏

JIT不会主动“猜”你的意图，但会忠实响应行为模式。以下写法能帮它更快识别并稳定优化：

• 避免在热点方法中频繁切换对象类型（如List>反复赋不同实现类），否则C2可能因类型不稳定放弃内联
• 把计算密集逻辑尽量收拢在单一方法内，而不是拆成多个小方法链——C1/C2对跨方法调用的内联有层级限制
• 初始化阶段（如Spring Bean创建）尽量不做重计算，这部分走解释器没问题；真正压测/业务请求进来后，JIT才开始发力
• 用-XX:+PrintCompilation观察哪些方法被哪一层编译，配合jstack看调用栈，确认热点是否落在预期路径上

代码缓存管理不能忽略

编译后的机器码全存在Code Cache里，空间不足会导致编译停滞甚至退回到纯解释执行：

• -XX:ReservedCodeCacheSize=256m（JDK8+默认240m）：对中大型应用建议设为384m或更高
• -XX:+UseCodeCacheFlushing：开启自动淘汰冷代码，默认已启用，但需确保-XX:CodeCacheMinimumFreeSpace足够（默认2m）
• 如果看到日志出现“CodeCache is full”，说明C2编译被阻塞，此时即使方法已达标也不会升级优化