HotSpot通过运行时计数器动态识别热点：InvocationCounter（方法调用）和BackEdgeCounter（循环回边）任一达到阈值（默认10000/140000）即触发JIT编译。
HotSpot 怎么判断一段代码是“热点”
HotSpot 不靠静态分析，而是靠运行时计数器动态识别热点。方法调用次数和循环回边次数分别对应两个独立计数器：InvocationCounter 和 BackEdgeCounter。只有两者之一达到阈值（默认分别是 10000 和 140000），才会触发 C1 或 C2 编译。
常见错误现象：本地测试时代码跑得飞快，但压测中没看到 JIT 编译日志——大概率是没跑够次数，或者 JVM 启动参数没开日志（比如漏了 -XX:+PrintCompilation）。
- 阈值可调，但不建议改：如
-XX:CompileThreshold=5000会加速编译，但也增加启动期 CPU 开销 - 分层编译（默认开启）下，C1 先编译，等更热再升到 C2；关掉分层（
-XX:-TieredStopAtLevel1）会让 C2 直接上，但首次编译延迟更明显 - 方法内联受
-XX:MaxInlineSize和-XX:FreqInlineSize控制，不是“够热就一定内联”，小函数才容易进内联队列
OSR 栈上替换到底替什么、什么时候替
OSR（On-Stack Replacement）只发生在**正在执行的长循环里**，不是替换整个方法，而是把当前栈帧里那个循环体的解释执行状态，替换成已编译好的机器码版本。替换后继续跑循环，但后续迭代走的是编译路径。
典型场景：一个大循环跑了几十万次才被判定为热点，但你不想等那么久才享受优化——OSR 就是为这种“已运行中+突然变热”的情况设计的。
立即学习“Java免费学习笔记（深入）”；
- 触发 OSR 的条件比普通编译更苛刻：必须是循环回边（loop back-edge），且计数器超
BackEdgeThreshold（默认 140000），同时该方法已通过 C1 编译或正排队等 C2 - 不能替递归调用栈：OSR 只作用于当前栈帧的循环体，上层调用栈仍是解释模式
- 用
-XX:+PrintCompilation看日志时，带osr标记的行就是 OSR 编译，例如：123 45 java.lang.String::hashCode (67 bytes) osr
JIT 编译失败或退优化（deoptimization）的常见诱因
编译不是一劳永逸。JIT 会基于假设做激进优化（比如假设某个字段永远不为 null），一旦运行时打破假设，就会触发 deoptimization：强制切回解释执行，并可能重新编译。
最常被忽略的一点：频繁的 deopt 会导致性能毛刺，但日志里往往只显示 made not entrant 或 made zombie，不报错也不警告。
- 常见诱因包括：类加载导致的虚方法表变更、断言失败、类型护盾（type profile）严重偏离预期、G1 GC 中的写屏障干扰逃逸分析
-
-XX:+PrintDeoptimizationDetails能打出退优化原因，但别在生产开——日志量极大 - 用
jstat -compiler <pid></pid>查看failed列，非零值说明有编译失败，常见于内存不足或代码太复杂（如超大 switch、嵌套过深）
怎么观察真实 JIT 行为，而不是猜
别信直觉，也别只看 PrintCompilation 的粗粒度日志。真正要定位问题，得组合几个低开销手段。
最容易踩的坑是：用 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly 却没装 hsdis，结果日志全是 [error occurred during printing]，还以为 JIT 没工作。
- 先确认是否真触发了编译：
jstat -compiler <pid></pid>看total和failed；jstack <pid></pid>查线程状态里有没有VM Thread长时间 RUNNABLE（可能卡在编译） - 想看某方法是否被内联：加
-XX:+PrintInlining，注意输出里inline (hot)或too big这类提示 - 需要汇编级验证？务必配好 hsdis（Linux 下通常叫
libhsdis-amd64.so），否则PrintAssembly形同虚设
真正难的从来不是“有没有编译”，而是“为什么这个关键路径没被内联”或者“为什么刚编译完就退优化了”——这些都得靠日志组合 + 代码特征交叉比对，没有一键答案。
