本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
Java 已经不是当年的 Java 了，它曾经给人的印象是启动慢、大内存、CRUD 等等，这其中的有些标签还总甩不掉，给其它语言的程序员带来了巨大的成见。
在云原生与 Serverless 时代，Java 应用的“启动慢、预热长”一直是架构师们心头的隐痛。但这一次，HotSpot JVM 决定不再妥协。随着 JEP 544（提前代码编译）正式被 Targeted 至 JDK 28，Java 的启动性能即将迎来范式级别的转变。
可这一切来的太晚了，现在已经是 AI 时代了，它才姗姗来迟。虽然这一次 JDK 28 是携带着 AOT 的快 + JIT 的稳 + Project Leyden 的里程碑，但当前的趋势已经不属于它了。
Java 慢
“Java 慢”——这个争议了二十多年的话题，可能很快就要被改写了。
对于微服务、Serverless、弹性伸缩容器这些场景来说，Java 应用最大的痛点从来不是跑得不快，而是启动慢、预热久。JVM 刚启动时只能跑解释执行，等 C1、C2 编译器逐步把热点代码编译成机器码，性能才慢慢爬到峰值。这个“爬坡”过程可能持续几分钟甚至更久，导致新扩容的实例在相当长一段时间里只能以“半血”状态接流量。
曾经也有不少网友吐槽过，比如双十一等，遇到突发流量，别的语言启动了之后能立马就绪，而 Java 则说再等等，马上满血可用。同样的扩容，它就是慢半拍。
文章中多张配图参见：https://mp.weixin.qq.com/s/8HUQSFYt4YlOwVj5AKGldQ。
这一切要结束了。2026 年 9 月，OpenJDK 首席架构师 Mark Reinhold 在 jdk-dev 邮件列表上宣布，JEP 544（Ahead-of-Time Code Compilation，提前代码编译）正式 Target JDK 28。在 9 月 21 日提出后无人反对，按照 JEP 2.0 流程正式定标。随后，JDK 28 的早期访问版 Release Notes 已将其列入“Notable Features”，最新版本 Build 20 更新于 2026 年 10 月 16 日。
这意味着，从 JDK 28 开始，HotSpot JVM 启动的那一刻，优化的原生机器码就已经在内存里躺着了。可以说是，JEP 544 让 JVM 应用真正的做到“出生即巅峰”。
JEP 544 到底做了什么？
先看官方一句话总结：
通过在训练运行（training run）中把应用程序代码编译为原生代码、并将其存入 AOT 缓存供后续生产运行使用，使优化后的原生代码在 HotSpot JVM 启动时立即可用，从而改善启动和预热时间。如果生产中的工作负载发生变化，则动态重新生成本地代码以保持峰值性能，兼得 AOT 与 JIT 两者之长。
说白了，它解决的核心矛盾是 JIT 编译的质量高，但来得太晚；AOT 编译来得早，但之前只能在“换 JVM”（如 GraalVM Native Image）的前提下实现，代价巨大。
JEP 544 的思路非常巧妙，不换 JVM，不离开 HotSpot，而是把原本 JIT 在运行时辛辛苦苦编译出来的机器码，在训练运行中提前生成好，连同类加载\链接状态、方法剖析数据一起打包进 AOT 缓存。生产环境启动时，JVM 直接从缓存加载这些原生代码，跳过了解释执行和层层编译的整个爬坡过程。
打个比方，以前的 Java 应用像一个每次上班都要“热身两小时”的运动员；现在相当于把热身过程录下来存档，每次到岗直接以最佳状态开赛。
Project Leyden 的五年铺垫
JEP 544 是 Project Leyden 路线的压轴之作。回看这条时间线，每一步都在为“缓存更多运行时产物”打基础。
| JEP | 内容 | 落地版本 |
|---|---|---|
| 483 | AOT 类加载与链接（AOT 缓存初登场） | JDK 24 |
| 514 | 一行命令创建缓存，工效学优化 | JDK 25（LTS） |
| 515 | AOT 方法剖析数据缓存，加速预热 | JDK 25（LTS） |
| 516 | 缓存兼容任意 GC（含 ZGC） | JDK 26 |
| 544 | AOT 代码编译，缓存真正的机器码 | JDK 28 |
可以说，前面四个 JEP 把“类元数据、堆对象、剖析数据”都存进了缓存，而 JEP 544 补上最后也是最关键的一块拼图，编译后的本地代码本身。社区普遍认为这标志着 Leyden 项目进入“冲刺收官”阶段。
所以，JEP 544 从一开始它的设计目标就很明确，不需要对应用程序、库或框架的代码进行任何修改，也无需复杂的 HotSpot 配置，只需请求使用 AOT 缓存即可。
现在，它作为 Project Leyden 的核心成果之一，JEP 544 的 Targeted 标志着 HotSpot 原生补齐了启动速度的短板。社区甚至将其评价为“HotSpot 对 GraalVM 启动时间垄断的一次漂亮反击”。
效果有多夸张？
根据 JEP 中报告的评测数据，在双核 Linux/x64 机器上、对五个基于流行框架构建的基准应用进行测试，在已有 AOT 缓存（类与对象缓存）的基础上再叠加 AOT 代码编译，启动时间缩短幅度从约 50–70% 提升至约 65–80%。
这个数字的含义是，一个原本需要 10 秒启动、再花几分钟预热的应用，在理想情况下可能 2~3 秒就“带着峰值性能”就绪。对于按 100ms 粒度计费的 Serverless 场景、对弹性扩容敏感的 K8s 服务来说，这是性质上的改变，而不仅是优化。
而且这还只是 JEP 草案阶段的预发布数据，正式交付时数字可能还会更好。
与 GraalVM 的区别
谈到 AOT，很多人第一反应是 GraalVM。ej-technologies 甚至直接用“HotSpot Strikes Back（HotSpot 的反击）”来评价这一 JEP，认为它将使 HotSpot AOT 缓存的启动性能匹敌 GraalVM，却“无需承受它的痛苦”。
两者关键的区别在于：
- GraalVM Native Image 是“封闭世界”：一切必须在构建期可知，运行时不能动态加载新类，反射、动态代理、JNI 都需要额外元数据配置，构建过程沉重。开发日常往往还得维护 JVM 和 Native 两套构建。
- JEP 544 是“开放世界”：你用的还是那个完整的 HotSpot JVM——反射照常、动态类加载照常、所有 GC 可选（ZGC 也在 JEP 516 之后完全兼容）。如果生产负载和训练负载不符，JVM 会
动态地重新 JIT 编译，始终维持峰值性能。
以至于不少老外对其赞不绝口，称这才是“两全其美”的真正含义。
怎么用？
在 JDK 28 中，整个流程与 JEP 483/514 建立的工效学保持一致，大致上需要三步走。
# 1. 训练运行：录制应用的类加载与执行信息
java -XX:AOTMode=record -XX:AOTCacheOutput=app.aot -cp app.jar com.example.Main
# 2. 离线创建 AOT 缓存（含原生代码生成）
java -XX:AOTMode=create -XX:AOTCacheOutput=app.aot -cp app.jar
# 3. 生产运行：直接挂载缓存
java -XX:AOTCache=app.aot -jar app.jar上面的 3 步，基本上完美的体现了 JEP 544 的核心思路，简单粗暴且高效，既然生产环境预热太慢，那我们就提前“模拟考”！
- Training Run（训练运行）：在上线前，让 JVM 先跑一遍真实业务场景，把哪些方法是“热点”摸得清清楚楚，并直接编译成优化好的“原生代码”。
- AOT Cache（提前编译缓存）：把这些最优解打包存进缓存里。
- Production Run（生产运行）：正式上线时，JVM 启动直接读取缓存！相当于带着满分攻略进考场，第一秒就直接进入“巅峰状态”，彻底跳过缓慢的预热阶段。
这些步骤，对应用代码、库、框架完全不需要修改，这也正是该 JEP 的明确设计目标之一。
不过需要注意的是：
- JEP 544 不是“免费午餐”。训练运行和缓存生成需要纳入 CI/CD 与发布流程，缓存产物需要随应用版本管理；负载模式大变的应用需要重新训练。
- JDK 28 是非 LTS 版本。预计 2027 年 3 月发布，想用在生产上的企业更可能等待它向后移植到 LTS 线。
- 训练负载要代表性。社区讨论中也有人关心迭代式训练运行的合并进展，如何低成本地让缓存跟上代码与负载的演进，仍是活跃话题。
结语
JEP 544 的意义，不在于又一个“启动优化”数字，而在于它改变了 Java 性能模型的基本假设。从“先慢后快、慢慢爬坡”，变成“起步即峰值、全程不掉线”。它与 JDK 28 中另外两项 ZGC 启动优化 JEP（545、546）一道，把冷启动这个 Java 云原生化的最后一块短板，补得七七八八了。
对于二十多年“Java 启动慢”的老梗来说，这可能不是终点，但绝对是故事反转的开始。
它并不取代 JIT，而是与 JIT 协同工作。让 Java 程序既享受了 AOT 的“秒级启动”，又保留了 JIT “越跑越快”的动态适应能力。
最后，期待更多且好用的 JEP 尽快落地，让 Java 再次伟大！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Java 的云原生时代来了，启动提速 65%~80%！