热点代码是JVM运行时因高频调用或循环迭代（如方法调用≥10000次或回边≥10000次）被识别并优化的逻辑，判断依据是Invocation Counter和Back Edge Counter两个计数器。
热点代码就是 JVM 在运行时发现“被反复执行”的那段逻辑——它不看代码多炫酷，只认调用频次和循环次数。真正影响性能的往往不是启动慢，而是某段方法每秒被调用几千次、或某个循环体跑了上百万次。JVM 不会一上来就优化全部代码，而是等它“热起来”才出手。
怎么判断一段 Java 代码是不是热点？
JVM 内部靠两个计数器实时盯梢：Invocation Counter（方法调用计数器）和 Back Edge Counter（回边计数器，专盯循环）。默认阈值在 Server 模式下是 10000 次调用或循环迭代，达到就标记为热点。
- 不是你写完就“热”，而是运行中被真实高频触发才会被识别
- 即使一个方法只调用一次，但里面有个
for (int i = 0; i ，JVM 也会通过回边计数把它当作热点 - 热度会衰减：计数器不是一直累加，而是按公式
H(t) = H₀·e^(-λt)随时间下降，避免短时流量尖峰误判 - 用
-XX:+PrintCompilation启动 JVM，控制台会打印哪些方法被 JIT 编译了——出现即说明已被识别为热点
为什么 String.length() 总是飞快？
因为它是个典型被 JIT 内联的热点小方法。源码里就一行 return value.length，字节码不到 35 字节，完全满足内联条件。JIT 编译后，调用直接变成字段读取，连方法栈帧都省了。
- 内联不是编译期行为，而是 JIT 在运行时动态做的：把
str.length()替换成对str.value.length的直接访问 - 你可以用
-XX:+PrintInlining看到类似输出：inline (hot) java.lang.String::length - 如果自己写个 50 行的
process()方法，哪怕被高频调用，JIT 默认也不会内联——超出了-XX:MaxInlineSize（默认 35）限制 - 盲目增大
MaxInlineSize可能导致代码缓存膨胀，反而降低 CPU 指令缓存命中率
自己写的高频方法为啥没被 JIT 优化？
常见原因不是 JVM 懒，而是你无意中“拦住了”它的识别路径。
立即学习“Java免费学习笔记（深入）”；
- 方法太长或含大量分支/异常处理，JIT 认为优化收益低，跳过编译
- 用了
final以外的虚方法调用，且类加载后又动态加载了子类（破坏了 CHA 类型分析前提），JIT 无法安全内联 - 应用刚启动就压测，JVM 还在解释执行阶段，计数器没攒够阈值——等几十秒再看
PrintCompilation输出 - 开了
-Xint（纯解释模式）或-XX:TieredStopAtLevel=1，直接禁用了 C2 编译器，热点永远得不到深度优化
最常被忽略的一点：热点识别依赖真实负载。本地跑个 for 循环 10 万次，不一定触发 JIT；但线上服务每秒处理 2000 QPS，某个 calculateScore() 被调用上万次，它立刻就会变热——别只盯着代码，得看它在生产环境里到底“忙不忙”。
