什么时候该调大 -XX:CompileThreshold
默认值 10000 意味着方法被解释执行满一万次才触发 C1 编译，对高并发短生命周期服务（比如 Spring Boot Web API）来说太保守——热点方法还没来得及编译，请求潮就过去了，C2 更是遥遥无期。
实操建议：
- 测试环境可先试 -XX:CompileThreshold=1500，观察 PrintCompilation 日志里方法编译延迟是否明显缩短
- 生产环境慎用低于 3000 的值，否则 C1 编译线程争抢 CPU，反而拖慢吞吐
- 注意：该阈值只影响 C1，C2 触发靠的是更复杂的热度模型（如 backedge 计数），不能靠它“催熟”C2
C1 和 C2 共存时，哪些函数会优先走 C2 编译
C2 不是“更高级所以全上”，而是有明确偏好：长循环、大量浮点运算、频繁调用虚方法（如接口实现类多态分派）、含 synchronized 块但锁竞争低的代码段，更容易被 C2 拦截编译。
常见错误现象：
- 用 jstack 看到线程卡在 Unsafe.park，但 PrintCompilation 显示全是 C1 编译记录 → 可能 C2 被抑制了
- GC 日志里 ConcurrentMarkSweep 或 G1 Evacuation 阶段耗时突增 → C2 正在后台密集编译，抢占 GC 线程资源
实操建议：
- 加 -XX:+TieredStopAtLevel=1 强制只用 C1，用于快速验证是否 C2 编译引发毛刺
- 若确认 C2 是瓶颈，改用 -XX:TieredStopAtLevel=3（C1+C2 全开）并配 -XX:CICompilerCount=4（四核机器下给编译器留足线程）
-XX:+UseBiasedLocking 在分级编译下的真实表现
这个参数在 JDK 6–8 默认开启，但到了 JDK 10+ 默认关闭，不是因为没用，而是它和 C2 的锁消除（lock elimination）逻辑存在隐式冲突：C2 优化时假设锁可能被偏向，但运行时偏向锁撤销又触发 safepoint，反而打断编译流水线。
使用场景：
- 单线程或极少线程竞争的 OLAP 批处理任务，开启后确实减少 monitorenter 指令开销
- 高并发 Web 服务（Tomcat/Spring Boot），开启后反而增加 safepoint 停顿频次，尤其在 CMS 收集周期内
实操建议：
- JDK 8u202+ 环境下，直接移除该参数，让 C2 自主做锁粗化（lock coarsening）和消除更可靠
- 若必须保留，需同步加 -XX:-UseCounterDecay（禁用热点计数衰减），否则 C2 会误判方法热度下降而降级回解释执行
如何用 jstat 实时判断 C2 是否被挤占资源
jstat -compiler 输出里的 failed 列非零，或 invalid 持续增长，基本等于 C2 编译队列已溢出——不是代码写得差，是编译线程不够或内存不足。
立即学习“Java免费学习笔记（深入）”；
性能影响：
- 编译失败的方法会退回解释执行，CPU 利用率可能不升反降（解释器比 C1/C2 慢 3–5 倍）
- 多个服务共用同一台物理机时，一个 JVM 的 C2 队列积压会拖慢其他 JVM 的 GC 响应
实操建议：
- 查看 jstat -gc 中 CCSC（压缩类空间容量）是否接近 CCSU（已用），若差值
- 紧急缓解：加 -XX:ReservedCodeCacheSize=512m（默认 240m），但别超 1g，否则浪费堆外内存
- 长期方案：用 -XX:+PrintNMethods 抓取高频编译失败的方法名，针对性用 -XX:CompileCommand=exclude,ClassName::methodName 排除非核心路径
分级编译不是开几个参数就完事，C1 和 C2 对同一段字节码的优化策略可能完全相反，而 JVM 不会告诉你哪条路径被哪个编译器接管了——得靠 PrintCompilation 和 jstack 对齐时间戳，才能看清真实流向。
