hot code 是 jvm 运行时统计出的被反复执行的方法或循环体，非静态标记；jit 通过调用计数器（如默认10000次）或回边计数（如server vm默认10700次）动态识别并触发编译。
Hot Code 是什么，JIT 怎么盯上它
Hot Code 不是写法特殊、也不是加了注解的代码，而是 JVM 运行时发现「被反复执行」的方法或循环体。JIT 编译器不会一启动就编译所有方法，而是靠计数器动态识别：比如一个方法被调用超过 CompileThreshold 次（默认 10000），或者某个循环体回边（back-edge）执行超阈值（Client VM 默认 1400 次，Server VM 默认 10700），就会被标记为 hot 并排队编译。
关键点在于：hot 是运行时统计出来的，不是静态标记的；哪怕你写了 @HotMethod（这根本不存在），JVM 也完全无视。
怎么验证某段代码真被 JIT 编译了
光看逻辑“应该很热”没用，得实锤。最直接的方式是加 JVM 参数观察日志：
-
-XX:+PrintCompilation：输出每次编译的方法名、层级（C1/C2）、耗时，例如123 45 3 java.lang.String::hashCode (67 bytes) -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining：看内联决策，常和 hot 方法强相关 -
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation：生成详细 XML 日志（需配合hsdis查看汇编）
注意：-XX:+PrintCompilation 在容器环境或高并发下容易刷屏，建议搭配 -XX:LogFile=compile.log 重定向；另外 JDK 17+ 默认关闭 C2 编译器（GraalVM 或 ZGC 场景下），PrintCompilation 可能只显示 C1 编译记录，别误判成“没编译”。
立即学习“Java免费学习笔记（深入）”；
为什么有些高频方法就是不进 JIT
常见假性“不热”现象，其实背后有硬约束：
- 方法体太大（默认 > 8000 字节字节码）：触发
TooLarge拒绝，可通过-XX:MaxTrivialSize或-XX:MaxInlineSize微调，但治标不治本 - 包含未解析符号（如类还没加载完、invokedynamic 目标未稳定）：JIT 会跳过，等下次统计周期再试
- 刚启动阶段（前几秒）：JVM 处于解释执行预热期，
CompileThreshold计数器尚未生效，此时看-XX:+TieredStopAtLevel=1强制只用 C1 能更快看到编译日志 - 被
-XX:CompileCommand=exclude显式排除，或方法签名匹配了黑名单规则
一个典型坑：单元测试里循环调用 10000 次 ArrayList::add，结果没编译——因为测试太短，JVM 还没完成类初始化或 GC 就结束了，计数器根本没攒够。
影响 JIT 编译效果的关键参数
默认值适合通用场景，但压测或低延迟服务常要调：
-
-XX:CompileThreshold=1000：降低触发门槛（注意会增加编译线程开销） -
-XX:TieredStopAtLevel=4：强制走 C2（Server VM 下默认值，但 OpenJ9 或某些容器镜像可能改过） -
-XX:ReservedCodeCacheSize=512m：避免 code cache 满导致编译静默失败（查java -XX:+PrintCodeCache确认） -
-XX:+UseStringDeduplication：间接影响字符串密集型方法的热度判定（减少对象分配，改变调用模式）
真正难调的不是参数本身，而是不同 JDK 版本对「hot」的定义在变：JDK 8 的回边计数逻辑和 JDK 17 的 GCM（Garbage-First + JIT 协同）下统计粒度不同，同一段代码在两个版本里 hot 状态可能不一致——别直接套用旧项目的调优经验。
