JVM通过热点探测（方法调用计数器和回边计数器）触发JIT分层编译：先C1编译基础优化，再C2编译激进优化；内联受字节码长度、虚方法特性等约束；去优化机制保障正确性但影响性能。
JVM不会一启动就编译所有代码，它只对真正“跑得多”的代码下手——这个判断过程就是热点探测，触发后的编译才是JIT优化落地的关键环节。
热点探测不是凭感觉，而是靠两个计数器硬统计
JVM在解释执行时，默默给每段代码记两笔账：
-
method invocation counter：方法被调用的次数，比如calculate()被循环调用了 100 万次 -
back-edge counter：循环体内部“跳回头”执行的次数，比如for循环里每次i++后判断条件成立又跳回去，就算一次回边
默认阈值都是 10000（可通过 -XX:CompileThreshold 修改），但注意：这个阈值仅对分层编译中的 C1 编译生效；C2 编译还会叠加更严的热度要求（如方法内联深度、类型稳定性等）。单纯调用多，不等于立刻进 C2。
编译不是“全量重写”，而是按层级渐进升级
JIT 编译是分阶段推进的，不是“要么不编，要么全优化”：
- 刚启动时：纯解释执行，快但慢
- 第一次达标（如调用超 10000 次）：C1 编译器介入，生成带基础优化（如公共子表达式消除、简单内联）的机器码，编译快、开销小
- 持续高频 + 类型稳定 + 无去优化风险：C2 编译器接手，做激进优化（如逃逸分析、循环展开、冗余分支裁剪），生成高度定制的本地代码
你可以用 -XX:+PrintCompilation 看到类似这样的日志：123 45 3 com.example.HotSpotDemo::calculate (12 bytes)，其中第3列的 3 就代表 C2 编译级别。如果只看到 1 或 2，说明还没升到深度优化阶段。
内联不是无脑展开，而是一套带约束的决策链
内联（inlining）是 JIT 最典型的优化动作，但它绝不是“看见小方法就塞进去”：
- 方法字节码长度 ≤
-XX:MaxInlineSize（默认 35 字节）才考虑内联 - 虚方法（如被
override的实例方法）需满足“单实现推测”（monomorphic call site），否则会退化为去虚拟化（devirtualization）或放弃内联 - 递归调用、含异常处理块、含同步块的方法，默认被排除在内联候选之外
- 内联后总字节码膨胀不能超过
-XX:FreqInlineSize（client VM 默认 325，server VM 默认 1000）
所以，private static int add(int a, int b) { return a + b; } 极大概率被内联；但 public String toString() { ... } 即使很短，也大概率不会——因为它是虚方法，且多数类有自定义实现，JIT 不敢轻易假设。
编译结果会被反复验证，不稳就退回到解释执行
JIT 编译的机器码不是一劳永逸的。一旦运行时发现原先的假设不成立（比如某个原本单实现的虚方法，突然加载了新子类并被调用），JVM 会触发 deoptimization（去优化）：把正在执行的机器码栈帧“拍平”，还原成解释器能理解的字节码状态，再从那里继续执行。
这种机制保证了正确性优先，但也意味着：频繁的类加载、动态代理、反射调用、Lambda 形变，都可能让 JIT “白忙一场”。如果你在 -XX:+PrintCompilation 日志里看到大量 made not entrant 或 made zombie，基本就是在提示：这段编译码已被废弃，当前走的是解释路径。
真正容易被忽略的，是“去优化成本”本身——它不报错、不抛异常，但会让某段本该飞起来的循环，突然掉回解释执行的速度档位，且难以通过常规 profiling 工具直接定位。
