Java程序越跑越快是因为JVM动态识别热点代码并触发JIT编译，而非简单开关；C1/C2编译策略、GC干扰、容器内存限制均影响编译时机与效果。
Java程序为什么有时越跑越快？——JIT不是开关，是动态决策系统
Java程序启动后执行变快，不是因为“JIT打开了”，而是JVM在运行时持续观察哪些方法被频繁调用（比如 String.hashCode()、ArrayList.get()），一旦某方法被判定为“热点代码”（默认阈值：C1编译器1500次，C2编译器10000次），才触发编译。这个过程完全自动，不依赖你写什么注解或配置。
容易踩的坑：
- 误以为加了 -XX:+TieredStopAtLevel=1 就能“强制只用C1”，结果发现短生命周期应用反而更慢——C1生成的代码优化浅、但编译快；C2优化深、但耗时久，对微服务类短平快应用可能根本等不到C2介入；
- 在压测前没“预热”，直接拿前10秒吞吐量当性能指标，这时JIT还没开始编译，数据毫无参考价值；
- 把 System.nanoTime() 测得的单次方法耗时当真——JIT编译期间会停顿（safepoint），且首次执行含解释开销，必须稳定运行数秒后再采样。
怎么确认某个方法真的被JIT编译了？——别信日志，看 PrintCompilation
JVM自带诊断开关，比任何第三方工具都准。启动时加上：-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation，就能看到实时编译记录，例如：
123 45 3 java.lang.String::hashCode (67 bytes) 201 67 4 java.util.ArrayList::get (12 bytes)
说明第123毫秒时，String.hashCode 被C3（tiered编译层级）编译完成，生成67字节机器码。注意：
- 行首数字是毫秒级时间戳，不是序号；
- 第二列是编译任务ID，重复ID代表同一方法多次重编译（常见于逃逸分析失败后回退）；
- 第三列是编译级别：1=C1 client，4=C2 server；
- 如果某方法反复出现又消失（如 1234 89 1 com.example.Xxx::calc (n methods) 后再无下文），大概率被C2编译后替换了，原C1版本被废弃。
为什么加了 -XX:+UseG1GC 后JIT行为突然异常？——GC与编译器共享 safepoint 机制
G1 GC 和 JIT 编译器共用 JVM 的 safepoint 机制：每次GC暂停或JIT编译插入检查点，都会让所有线程在最近的安全点停下。如果GC频繁（如堆碎片多、大对象直接进老年代），就会打断JIT编译流程，导致热点方法迟迟无法升到C2，甚至降级回解释执行。
实操建议：
- 观察 PrintGCDetails 输出中 GC pause 是否密集（尤其 G1 Evacuation Pause 高频）；
- 检查是否因字符串拼接产生大量临时 char[]，触发G1的混合回收，间接拖慢JIT；
- 不要盲目调大 -XX:CompileThreshold 来“减少编译压力”——这只会让热点代码更晚被优化，整体吞吐反而下降；
- 真正有效的是控制对象生命周期：用 StringBuilder 替代 + 拼接，避免 substring() 持有超大底层数组引用。
云环境里JIT还可靠吗？——容器内存限制会让JIT“饿死”
在Kubernetes里给Pod配 memory: 512Mi，JVM却默认按物理机规格分配元空间（Metaspace）和编译缓存（CodeCache）。一旦 CodeCache 满（默认240MB），JIT就彻底停止，所有新热点代码只能解释执行——此时CPU使用率可能很低，但延迟飙升。
立即学习“Java免费学习笔记（深入）”；
必须显式约束：
- -XX:ReservedCodeCacheSize=128m（根据应用大小设为96–256m之间）；
- -XX:+UseContainerSupport（JDK 10+默认开启，但旧镜像常关闭）；
- -XX:MaxRAMPercentage=75.0（替代过时的 -Xmx，让JVM感知容器内存上限）；
- 配合 jstat -compiler <pid> 查看 failed 列是否增长——非零即表示CodeCache已满或编译失败。
最麻烦的是：这种问题在线上低流量时段不暴露，一到高峰，新实例拉起，JIT饥饿，雪崩从第一个5xx开始。
