Java 想把热代码提前装进缓存，AOT 不是赶走 JIT

作者：林岚｜OC 开发者生态编辑

据 OpenJDK JEP 544，HotSpot 计划把训练运行中生成的优化机器码保存进 AOT 缓存，供后续运行使用，同时保留动态重新编译能力。截至 9 月 11 日，该提案状态为 Candidate，不能当作已经随某个正式 JDK 交付的功能。

一句话结论：这项方案想把已经做过的优化提前带到下一次启动，而不是把 Java 变成只能静态编译的程序；训练环境是否有代表性，将影响收益能否兑现。

启动成功，不代表已经跑到最佳状态

Java 服务从进程启动到稳定处理请求，中间可能经历几个不同阶段。首先要加载和初始化代码，然后运行时观察哪些路径常用，再逐步把热点转换成优化后的机器码。

因此，“端口已经能连接”与“系统已达到稳定吞吐和延迟”不是一回事。扩容时如果新实例还在预热，却立即承担与老实例相同的流量，用户可能先感受到尾延迟上升。

JIT 的优势来自观察真实行为，但观察和编译本身也消耗 CPU 与内存。对于生命周期较短或经常弹性扩容的服务，这笔投入可能反复发生，尚未充分回收就又结束了。

AOT 缓存希望减少的，就是这种重复学习和重复编译的一部分成本。

缓存里多了机器码，为什么仍然需要 JIT

JEP 544 的设计不是 AOT-only 模式。训练阶段生成的代码若适用，可以提前使用；若缺失、不兼容或不再适合当前工作负载，解释执行和 JIT 仍可接手。

这种选择保留了动态适应能力。一个服务工作日主要查订单，促销时却大量计算优惠，热点可能发生变化。提前准备的代码可以帮助起步，但不应把未来所有运行都锁在训练阶段的假设里。

可以把它理解为带着经验上岗，而不是拒绝继续学习。这也解释了为什么“提前编译”并不必然意味着放弃 JVM。

训练跑得顺，不代表生产能照单全收

提案要求训练和后续运行在关键条件上保持相近，机器码使用还受到 CPU 架构、特性以及垃圾回收器等条件约束。缓存不适用时应回退，而不是强行执行不匹配的代码。

这里的训练也不是 AI 模型训练，而是运行应用以收集有代表性的行为并生成缓存。这个词相同，工程对象完全不同。

对团队而言，需要思考训练输入覆盖了什么。如果只触发健康检查，没有走过真实业务路径，缓存就可能对启动后的主要请求帮助有限。如果使用过于特殊的样本，也可能让结果过度偏向某一类操作。

不过，代表性不足不应被描述成必然破坏正确性。按方案设计，运行时仍有动态调整能力；更直接的影响通常是预期性能收益没有出现。

“启动缩短八成”必须带着测试条件阅读

提案展示了若干框架应用在双核 Linux/x64 条件下的测试，包含机器码的 AOT 缓存相对无缓存基线，启动时间缩短约 65%—80%。

这个范围不是所有 Java 应用的保证，也不是在此前缓存优化之上再统一打两折。比较时首先要看基线包含什么，不能把不同阶段的收益简单相加。

更重要的是，应用启动可能还包含数据库连接、远程配置、缓存加载和外部服务等待。这些工作如果占据主要时间，编译优化再明显，也不会按同样比例缩短整条启动链路。

验收应该观察一段时间，而不只是一个时间点

只测进程启动到端口开放，容易错过预热收益，也容易忽略准备缓存的成本。

更完整的评估应覆盖启动期间资源占用、第一批请求延迟、达到稳定状态的时间，以及负载变化后的表现。缓存生成和分发是否可靠，也属于部署成本。

同时保留回退演练。团队应知道缓存不匹配时服务如何表现，监控能否区分“正确回退但变慢”与“功能故障”。否则，一个本来可以平稳降级的机制，也可能因为缺少解释而变成排障噪音。

关键事实

• JEP 544 当前为 Candidate，不是已承诺交付的正式版本功能。
• 目标是在 AOT 缓存中保存训练运行生成的机器码。
• AOT 与 JIT 共存，方案不提供纯 AOT 模式。
• 测试收益依赖应用、基线和运行环境。

OC 判断

Java 的这条路线很务实：减少重复准备，又保留动态优化的余地。对开发者而言，最值得期待的不是一个更漂亮的启动数字，而是扩容和短生命周期任务能否更快进入稳定工作状态。

为什么重要

• 对开发者：理解启动、预热和稳态三个不同指标。
• 对运维团队：缓存生成与兼容性需要纳入发布流程。
• 对企业：用真实服务负载验证收益，不按框架演示推算容量。

参考来源

• OpenJDK：JEP 544 — Ahead-of-Time Code Compilation