分层编译解决“启动慢”与“峰值低”的矛盾：0级解释保启动，1级C1提速稳响应，2/3级采集profile为C2铺路，4级C2激进优化争峰值，五层协同实现冷热代码的动态适配。
分层编译解决的是“启动慢”和“峰值低”的矛盾
OpenJDK默认启用分层编译（TieredCompilation），根本原因不是为了“更先进”，而是为了解决解释执行太慢、C2编译太重、C1又不够用这三者之间的现实拉扯。不启用分层时，HotSpot只能在“纯解释”“C1快速编译”“C2深度优化”三者中二选一；而分层让它们共存并按热度自动流转。
五层编译器各自承担什么角色
分层编译实际包含五个层级（0–4），每层对应不同编译策略和触发条件：
-
Level 0：纯解释执行，无编译开销，但每次执行都查表跳转 -
Level 1：C1编译（Client Compiler），带基础优化（如方法内联、空值检查消除），编译快、代码体积小，适合短生命周期方法 -
Level 2：C1编译 + 调用计数采样，用于识别真正热点 -
Level 3：C1编译 + 更多profile信息（如分支频率、类型推测），生成更稳的中间代码 -
Level 4：C2编译（Server Compiler），做激进优化（如循环向量化、逃逸分析、去虚拟化），但编译耗时长、内存占用高
关键点在于：Level 2/3不是独立编译器，而是C1的增强模式——它不生成最终机器码，只为C2提供高质量运行时反馈数据。
为什么不能直接用C2编译所有方法
C2虽然产出性能最好的代码，但代价明显：
- 单个方法编译耗时可能达几十毫秒，对Web请求类应用是不可接受的延迟
- 编译线程本身会抢占CPU，尤其在高并发场景下反而拖慢响应
- C2需要大量profile数据才能安全做激进优化，冷启动时这些数据根本不存在，强行编译容易生成错误或低效代码
- 编译缓存（
CodeCache）空间有限，默认仅240MB，C2代码膨胀快，容易触发CodeCache is full警告甚至退回到解释执行
所以分层的本质是“用C1保响应，用C2争吞吐”，而不是技术堆砌。
关闭分层编译（-XX:-TieredCompilation）的实际影响
禁用后，HotSpot退回到传统混合模式，行为取决于JVM参数：
- 加
-client（已废弃）→ 只用C1，无后续升级路径 - 加
-server（已默认）→ 直接用C2，但所有方法都得等C2编译完才执行，冷启动卡顿明显 - 不加任何参数 → 实际仍走分层，只是层级逻辑被绕过
生产环境极少禁用分层。真要调优，更常见的是调整各层阈值（如-XX:CompileThreshold=1000）或限制C2介入时机（如-XX:Tier3InvokeNotifyFreqLog=10），而不是一刀切关掉。
最易被忽略的是：分层决策完全基于运行时统计，不是静态分析。哪怕你把main()标成@HotSpotIntrinsicCandidate，它也不会提前进C2——得先被调够次数、被C1跑出足够profile，才可能升到Level 4。
