为什么 JVM 不全程使用 JIT 编译？

在讨论 Java 性能时，一个常见问题是：既然 JIT 编译后的代码通常比解释执行更快，那为什么主流 JVM 不直接对所有代码都做 JIT 编译？表面上看，全程编译似乎能获得最佳执行性能，但真实设计要复杂得多。执行引擎的取舍并不只是“编译快还是解释快”的单一比较，而是启动时间、内存占用、编译开销、热点识别、部署复杂度与峰值性能之间的综合权衡。

本文从 JVM 执行引擎的基本模型出发，逐步拆解“是否全程 JIT”“为什么混合执行更常见”以及“不同方案适用于哪些场景”这几个问题。

---

一、先厘清问题：JVM 并不只有一种执行方式

“JVM 不用 JIT 全程编译”这个说法，严格来说只对部分 JVM 成立。JVM 是一种规范，并不限定实现必须采用解释器、JIT 编译器或 AOT 编译器。不同 JVM 实现可以自由选择执行引擎，因此不能把所有 JVM 一概而论。

如果按执行方式分类，常见 JVM 实现大致可以归为以下几类：

1. 混合执行模式
   以解释器为基础执行代码，同时通过热点探测识别高频方法，只对热点代码做 JIT 编译。这是许多通用 JVM 的默认模式。

2. 纯 JIT 编译模式
   不包含解释器，所有方法在执行前都会先经过 JIT 编译。部分面向服务器场景的 JVM 采用这种设计。

3. AOT + JIT 混合模式
   在部署阶段先将字节码编译为本地代码，降低首次运行时的解释或编译压力；运行期仍可对热点做进一步 JIT 优化。

4. 纯 AOT 模式
   运行前完成全部编译，运行时不依赖解释器和 JIT 编译器。这种模式常见于启动时间敏感或资源受限的场景。

因此，是否“全程 JIT”，本质上取决于具体 JVM 实现的设计目标。更值得讨论的问题是：为什么大量 JVM 选择不为所有代码做 JIT 编译。

---

二、执行引擎的基本成本模型

要从原理上理解这一设计，需要先区分两件事：

• 解释执行：JVM 逐条读取字节码指令，根据指令语义执行对应操作。
• JIT 编译执行：JVM 把字节码翻译为本地机器码，然后由 CPU 直接执行本地代码。

通常所说的“JIT 比解释快”，指的是“执行编译后的代码”比“解释器解释执行”更快，尤其是在循环、数值计算、方法调用等热点路径上。但这并不意味着“编译”这个动作本身没有成本。

抽象来看，解释执行路径是：

字节码 -> [解释器] -> 执行结果

而 JIT 执行路径是：

字节码 -> [JIT 编译器] -> 本地机器码 -> [CPU 执行] -> 执行结果

也就是说，JIT 方案中多出了“编译”这一前置阶段。虽然现代 JIT 编译已经非常快，但编译仍然需要 CPU 与内存资源。如果某个方法只执行一次，那么“编译一次 + 执行一次”的总耗时，很可能高于“直接解释执行一次”。

---

三、为什么“全程编译”并不总是划算

1. 冷代码的编译是净开销

业务系统中存在大量低频代码，例如启动配置加载、异常处理路径、日志初始化、一次性校验逻辑等。这些代码可能在整个进程生命周期内只执行一次或很少几次。对它们做 JIT 编译，不但不能通过后续高频执行摊薄编译成本，反而会拖慢启动过程。

例如下面这类方法在系统启动时只运行一次：

public void initOnce() {
    loadConfiguration();
    validateEnvironment();
    registerShutdownHook();
}

如果对 initOnce 做完整 JIT 编译，则需要先完成字节码到本地代码的翻译，再执行这段本地代码。而在解释执行模式下，JVM 可以直接解释执行字节码。对于这种一次性方法来说，解释执行更直接。

2. 编译会占用 CPU 与内存

JIT 编译是计算密集型操作，尤其是开启较高优化级别时，编译器需要进行内联分析、逃逸分析、循环优化、寄存器分配等工作。这些操作会消耗 CPU 和内存。

如果 JVM 对所有方法都进行高优化级别编译，那么在应用启动阶段可能出现明显 CPU 峰值，同时元数据、编译产物和优化信息也会增加内存占用。对于容器环境或资源受限场景，这种开销尤其敏感。

3. 启动性能与峰值性能存在矛盾

JVM 的一个重要设计目标，是在“应用启动快”和“长期运行性能高”之间取得平衡。

• 启动阶段：多数代码还未成为热点，适合解释执行或低级别编译。
• 稳定运行阶段：热点方法已经被识别，值得投入更多编译资源做深度优化。
• 长期服务阶段：峰值性能更重要，JIT 可以基于真实运行数据做激进优化。

如果一开始就全程高优化编译，启动时间会显著增加。而如果完全不编译，运行一段时间后的吞吐量又会受限。混合执行模式的核心价值，就是根据代码实际热度动态分配编译资源。

---

四、多层编译：兼顾启动与峰值性能

为了解决“编译太慢、解释太慢”的矛盾，许多现代 JVM 使用分层编译架构。其基本思路是：

1. 刚开始时，方法主要由解释器执行。
2. 当方法达到一定调用次数或循环次数阈值时，先用较低优化级别编译。
3. 方法继续变热后，再用更高优化级别重新编译。

分层编译可以看作一种渐进式投入策略。对于短期运行的方法，只做低级别编译甚至不编译；对于长期热点方法，持续提升优化程度。

例如，一个热点累积过程可以简化表示为：

调用次数低  -> 解释执行
调用次数升高 -> 低优化级别 JIT 编译
调用次数很高 -> 高优化级别 JIT 编译

这种方式不仅降低了启动期开销，也让 JIT 编译器能够根据真实运行数据做更准确的优化。例如方法内联的候选、分支概率、类型分布等，都可以在运行时观察得到。这些信息是静态编译很难获取的。

---

五、纯 JIT 模式的现实方案

并非所有 JVM 都采用混合执行模式。一些专注于服务器端长期运行的 JVM 实现，会移除解释器，直接对所有方法做 JIT 编译。但这些实现通常也引入多层编译机制，而不是一开始就对所有方法进行最高级别优化。

其执行流程大致如下：

方法第一次执行前 -> 使用低优化级别快速编译
方法被频繁调用后 -> 使用更高优化级别重新编译

严格来说，这种模式仍然属于 JIT 编译，因为字节码是在运行期才被翻译为本地代码。同时它也具备自适应编译的特征，因为是否提升优化级别，依赖于运行期采集的热点信息。

这类执行引擎的典型特征包括：

• 没有解释器，避免了解释器的维护复杂度；
• 第一次执行前必须编译，可能带来明显的启动延迟；
• 对服务器应用更友好，适合启动后长时间运行的业务；
• 对短生命周期程序不够友好，因为编译成本可能无法被足够多次执行摊薄。

---

六、AOT 编译的补充角色

为了减少启动期解释和即时编译的开销，一些 JVM 还支持 AOT 编译。AOT 的思路是在部署或构建阶段提前完成字节码到本地代码的转换。这样应用启动时可以直接使用编译结果，而不必等待 JIT 预热。

AOT 的优势主要体现在：

• 降低冷启动耗时；
• 减少启动阶段 CPU 峰值；
• 对短生命周期服务更友好。

但 AOT 通常并不总能替代 JIT。因为运行期 JIT 可以利用真实运行数据做激进优化，而 AOT 在编译时缺少这些运行时信息。因此不少场景会采用“AOT 提供基础性能 + JIT 提供峰值性能”的组合方式。

例如：

构建阶段 -> AOT 编译 -> 产生基础本地代码
运行阶段 -> 直接执行基础本地代码
热点方法 -> JIT 进一步优化

这种方案适合对启动时间有严格要求，同时又需要长期稳定性能的服务。

---

七、JIT 与自适应编译并不冲突

一个容易混淆的点是：JIT 编译是否等同于自适应编译？实际上，两者是不同的概念。

• JIT 编译：指在运行期将字节码编译为本地代码，不一定基于热点信息。
• 自适应编译：指根据运行期行为动态决定是否编译、以何种优化级别编译。

既然“第一次执行前进行快速编译”也属于 JIT 编译，那么一个系统完全可以同时具备 JIT 编译和自适应编译特征：

第一阶段 -> 低优化级别 JIT 编译，保证代码可以执行
第二阶段 -> 根据热度提升优化级别，属于自适应优化

因此，讨论执行引擎时，不应把“JIT”简单等同于“只对热点做编译”。关键在于执行引擎是否在运行期生成并执行本地代码，以及优化决策是否依赖运行时信息。

---

八、如何理解主流 JVM 的选择

综合来看，主流 JVM 不采用全程高优化 JIT 编译，并不是因为 JIT 不重要，而是因为执行引擎需要同时满足多种目标：

• 启动时间不能过慢；
• 内存和 CPU 开销不能失控；
• 长期运行吞吐量要足够高；
• 编译资源要重点投入到真正影响性能的代码上；
• 短生命周期程序也要具备可接受的运行效率。

混合执行模式通过解释器承担冷代码执行，通过 JIT 编译器优化热点代码，再用多层编译分摊编译成本。对于大多数企业应用来说，这是一种更稳健的默认策略。

纯 JIT 模式更适合经过评估的服务器场景；AOT 模式更适合启动敏感场景；混合模式则在通用性、资源控制和性能表现之间取得了较好的平衡。

---

九、实践中的判断方法

技术选型时，不建议只凭“是否全程 JIT”做判断，而应结合实际业务特征评估执行引擎：

1. 应用生命周期长短
   短生命周期程序对启动敏感，AOT 或低优化编译可能更合适；长期服务可以接受逐步预热。

2. 是否频繁冷启动
   容器弹性伸缩、函数计算等场景经常重新拉起进程，此时启动性能权重更高。

3. 热点集中程度
   热点越集中，混合执行模式的收益越明显，因为少量热点方法可以被深度优化。

4. 部署资源约束
   如果 CPU 或内存紧张，需要关注 JIT 线程、编译产物和优化数据结构的额外开销。

5. 性能验收方式
   测试是否覆盖预热阶段？只测峰值性能会高估 JIT 收益，模拟真实启动与流量爬坡过程更合理。

---

十、总结

“JVM 不用 JIT 全程编译”这个说法，本质上描述的是主流 JVM 普遍采用混合执行模式这一现象，而不是所有 JVM 的统一设计。

从执行路径看，JIT 编译比解释执行快，指的是执行编译后的代码更快，而不是编译动作本身没有成本。对大量只执行一次的代码做编译，会增加启动延迟、CPU 消耗和内存占用，却无法获得足够的性能回报。

因此，更合理的策略是：

• 对冷代码使用解释执行或低级别编译；
• 对热点代码使用高优化级别 JIT 编译；
• 对启动敏感场景引入 AOT 编译作为补充；
• 通过运行时数据驱动编译决策，而不是对所有代码平均投入编译资源。

理解这些设计取舍，有助于开发者从“JIT 是否一定更好”的表层问题，进入执行引擎的工程权衡维度，也能更准确地评估不同 JVM 运行模式对业务系统的实际影响。