OpenJDK项目于9月10日将JEP544（Ahead-of-Time Code Compilation）更新为候选状态，这是Java平台在启动性能优化领域的一项重大架构演进。JEP544的核心设计是：在一次训练运行（training run）中，HotSpot JVM将应用代码编译为优化后的原生机器码并存入AOT缓存；后续生产运行时，JVM直接加载缓存中的预编译代码，使应用在启动瞬间即可达到接近峰值的性能水平，同时在工作负载变化时自动回退至即时编译（JIT）以维持最优性能。
Java启动性能的历史瓶颈
Java应用在HotSpot JVM上运行时需经历三个阶段：启动期（加载、链接、初始化类，通过解释器执行字节码）、预热期（热点方法逐步编译为C1编译器的中等优化代码）、以及峰值性能期（C2编译器将关键热点编译为高度优化代码）。对于微服务和Serverless场景，启动期和预热期的数十秒延迟是Java与Go、Rust等语言竞争时的核心劣势。JEP483（AOT类加载）和JEP515（AOT方法分析）已分别解决了类加载和方法画像的预计算问题，JEP544是这一系列优化的最后一块拼图。
JEP544的目标包括：使应用更快达到峰值性能、在工作负载变化时维持峰值性能、不修改应用代码或HotSpot配置、支持Serial/Parallel/G1/ZGC全部垃圾收集器、以及在AArch64和x64两种架构上可用。一个关键的设计约束是AOT编译不提供纯AOT模式——应用始终同时使用AOT和JIT编译代码，两者之间的切换对应用完全透明。
训练运行与生产运行的分离架构
在训练运行中，HotSpot按照正常流程启动应用，但在C2编译器将热点方法编译为高度优化代码的同时，将这些原生代码序列化存入AOT缓存。生产运行时，JVM启动即可从缓存中加载这些预编译代码，跳过解释器和C1编译阶段。当生产工作负载偏离训练期间的模式时，JVM会动态生成新的JIT编译代码替换AOT代码，整个过程对应用透明。
这一架构的核心优势是将Java应用的启动到峰值性能的时间从数十秒压缩到接近零，同时保留了JIT编译器根据实际工作负载进行运行时优化的全部能力。对于Kubernetes环境中频繁扩缩容的微服务，以及AWS Lambda等冷启动成本显著的Serverless平台，JEP544提供的启动加速效果将直接转化为用户体验改善和资源成本降低。微软Azure和亚马逊AWS均已公开支持这一优化方向，预计在JEP544正式发布后，主流云平台的Java运行时将第一时间集成AOT缓存支持，使用户无需手动配置即可享受启动加速。
JEP544不支持交叉编译（训练运行必须在与生产相同的CPU架构和特性集上执行），也不承诺支持HotSpot目前覆盖的所有CPU架构。这些限制在云原生场景中影响有限，因为大多数生产环境已在x64或AArch64标准化。JEP544的候选状态意味着其规范已稳定，预计将在下一个Java LTS版本中正式发布。