分层编译是JVM动态选择5级渐进优化策略的机制：0级纯解释执行，1级C1基础优化，2/3级C1+profiling，4级C2激进优化；触发依赖调用计数与回边计数，非固定阈值。
什么是分层编译？不是开关，是五级渐进优化策略
分层编译不是“开或关”的功能，而是 JVM 在运行时动态选择不同编译层级的机制。它把 HotSpot 的 JIT 编译拆成 5 层（0–4），从纯解释执行（level 0）逐步过渡到 C2 高度优化编译（level 4）。关键在于：**JVM 不会一上来就用最重的编译器，而是靠方法调用计数和回边计数决定何时升级**。
常见错误现象：java -XX:+TieredStopAtLevel=1 后应用反而更慢——这不是“禁用 C2”，而是强制卡在 C1（带少量优化的 client 模式编译器），对长周期服务不利；而 -XX:-TieredCompilation 则直接退回到仅 C1 或仅 C2 模式（取决于 -client/-server，但现代 JDK 已忽略该参数）。
- level 0：纯解释执行，无编译
- level 1：C1 编译，基础优化（如方法内联、空值检查消除），启动快
- level 2/3：C1 + 部分 profiling（如分支频率、类型信息收集）
- level 4：C2 编译，激进优化（循环展开、逃逸分析、向量化），耗时长但峰值性能高
什么时候该调 TieredStopAtLevel？看场景，不是看“要不要优化”
调整 TieredStopAtLevel 是在权衡“首次响应延迟”和“长期吞吐量”。它只影响新方法的编译起点，不影响已编译方法的降级或再编译。
使用场景：
- 短生命周期 CLI 工具（如构建脚本、命令行解析）：设为
-XX:TieredStopAtLevel=1，避免 C2 编译开销拖慢整体执行时间 - 微服务（Spring Boot 等）冷启动敏感：可尝试
-XX:TieredStopAtLevel=3，让热点方法快速获得 profile-guided 优化，又不等 C2 的长编译队列 - 长时间运行的大数据处理任务：保持默认（level 4），让 C2 充分发挥优势；强行限制到 level 3 反而可能因缺少逃逸分析导致更多堆分配
注意：-XX:TieredStopAtLevel=2 在 JDK 8u292+ 中已被废弃，行为等同于 level 1；JDK 17+ 默认启用分层编译，无需显式加 -XX:+TieredCompilation。
CompileThreshold 和分层编译共存时，谁说了算？
老教程常提 -XX:CompileThreshold=10000，但它在分层编译开启后**基本失效**。因为分层模式下，触发编译的阈值不再是固定数字，而是按层级动态变化的：
- level 1 触发：解释执行计数达 ~200（默认
-XX:TieredThresholdSize=50× 4） - level 4 触发：需先在 level 3 收集足够 profile 数据，再经二次计数（通常比纯 C2 模式晚 3–5 倍调用次数）
所以如果你发现加了 -XX:CompileThreshold=1000 却没看到更多方法被编译，不是 JVM 失效，而是分层逻辑接管了阈值判断。真要压低编译门槛，该调的是 -XX:TieredStopAtLevel 或 -XX:ReservedCodeCacheSize（防止 code cache 满导致编译停摆）。
容易被忽略的兼容性坑：GraalVM、ZGC、JDK 版本差异
分层编译不是“所有 JVM 实现都一样跑”。几个实际踩过的点：
- GraalVM CE 默认禁用分层编译（
-XX:-TieredCompilation），因为它用 Graal 编译器替代 C2，路径完全不同；硬加+TieredCompilation会导致启动失败或 fallback 到 C1 - ZGC + 分层编译在 JDK 11–15 有已知 bug：
java.lang.OutOfMemoryError: Compressed class space频发，根源是 ZGC 的并发类卸载与分层编译的多阶段类重定义冲突；JDK 16+ 修复，但生产环境仍建议搭配-XX:+UseZGC -XX:+TieredCompilation做充分压测 - JDK 8u212 之前，
-XX:TieredStopAtLevel=3在某些 GC 组合下会导致编译线程饿死；升级到 u292+ 可缓解
真正复杂的地方在于：分层不是独立模块，它和 GC、code cache 管理、类加载器生命周期深度耦合。改一个参数前，先看 -XX:+PrintCompilation 输出里 method name 后面的 tier 编号，比查文档更快定位是否如你所想地工作。
