JVM采用解释与JIT混合执行，是为了兼顾启动速度、长期性能和资源开销：解释器负责冷启动快速响应，JIT专注编译高频热点代码，通过方法调用与回边计数器精准识别并优化热路径，避免全编译延迟或纯解释低效。
JVM 采用解释执行与即时编译（JIT）混合运行的方式，不是为了折中妥协，而是基于启动速度、执行效率和资源开销三者之间的真实权衡。
为什么必须混合执行
解释器和 JIT 编译器各有不可替代的定位：
- 解释器负责“冷启动”：Java 程序一启动，字节码立刻可被逐条翻译执行，无需等待编译。这对快速响应、短生命周期应用（如脚本工具、单元测试）至关重要。
- JIT 编译器专注“热路径”：它不编译全部代码，只对反复执行的方法或循环体生成本地机器码。一次编译，多次高效执行——但编译本身有开销，频繁编译反而拖慢整体性能。
- 二者协同避免“全编译陷阱”：如果像 JRockit 那样完全去掉解释器，所有方法都得等 JIT 编译完才能运行，初始延迟明显；而若只用解释器，长期运行的业务逻辑（如订单处理循环、数据聚合）将始终低效。
热点代码如何被识别
HotSpot JVM 使用基于计数器的探测机制，不靠猜测，靠实测。核心是两个独立计数器：
- 方法调用计数器：统计某方法被调用的频次。Server 模式默认阈值为 10000 次，Client 模式为 1500 次。注意它不是累计总次数，而是带“半衰期”的活跃频率——超过半衰周期未达阈值，计数器自动减半（通常在 GC 时触发）。
- 回边计数器：专用于循环体，统计字节码中“向后跳转”指令（如 goto、if_icmpne 的循环回跳）的执行次数。Server 模式默认约 10700 次。它不衰减，一旦溢出即触发 OSR（栈上替换），让正在运行的循环直接切换到已编译的机器码版本。
混合模式的实际表现
默认的 -Xmixed 模式下，JVM 动态调度执行方式：
- 方法首次调用 → 解释执行，同时计数器+1；
- 计数器达阈值 → 向 JIT 提交编译请求，后台异步编译；
- 下次调用该方法 → 若编译完成，直接跳转执行缓存的机器码；否则继续解释执行；
- 若编译优化激进（如内联了已被重载的虚方法），后续类加载导致假设失效 → JIT 可逆优化（deoptimization），退回到解释执行，保障语义正确性。
不是所有高频代码都会被 JIT
判定是否“热点”，关键不在绝对次数，而在是否值得投入编译成本。例如：
- 一个空 while(true) 循环虽执行极多，但无实际计算，JIT 通常忽略；
- 一个仅在初始化阶段调用 20000 次的配置解析方法，因半衰期后计数归零，不会触发编译；
- 被频繁调用但含有大量反射、JNI 或异常分支的方法，JIT 可能降级为 C1 编译（轻量优化）而非深度优化的 C2。
这种设计让 JVM 在不同场景下都能保持合理响应与长期吞吐的平衡——不复杂，但每一步都有明确取舍。
