JDK 26 AOT 对象缓存怎样减少启动工作

JDK 26 的 AOT 对象缓存解决的是一个很具体的问题：Java 程序每次启动时，都要重新完成一部分类加载、链接和对象准备工作。JEP 516 把 AOT 缓存中的堆对象改成 GC 无关的归档格式，运行时按对象逐个加载并建立引用，因此缓存不再只适用于某一种垃圾收集器，包括 ZGC 在内的 GC 都可以使用这条优化路径。它不会把任意应用自动变成“零启动”，但能把重复的启动准备工作变成可以随应用一起交付的产物。

官方地址：https://docs.oracle.com/en/java/javase/26/

JDK 26 到底减少了哪部分启动工作

传统启动流程里，JVM 需要加载类、解析链接关系，并准备一批应用启动阶段会反复创建或访问的对象。JDK 24 引入的 AOT 缓存已经能够容纳类和堆对象；JDK 26 的 JEP 516 调整了对象部分的保存与恢复方式：构建阶段保存对象之间的索引关系，运行阶段再按当前 GC 能接受的方式分配对象并把索引重新连成引用。

这带来两个实际边界。第一，AOT 缓存是启动优化，不是业务缓存，不能代替数据库缓存或应用自己的对象池。第二，缓存适合稳定的启动路径；如果训练时没有走到某个功能，它就不会因为“理论上可能使用”而自动出现在缓存里。

先用代表性工作负载完成训练

训练阶段的目标不是立刻生成最终缓存，而是让 JVM 记录“哪些启动类、链接关系和对象值得归档”。下面的命令把训练配置和缓存输出放在同一个版本目录中，便于后续组装阶段读取：

# 训练代表性启动路径，只记录 AOT 配置与缓存产物位置
java \
  -XX:AOTMode=record \
  -XX:AOTConfiguration=build/aot/app.aotconfig \
  -XX:AOTCacheOutput=build/aot/app.aot \
  -jar app.jar

训练时应覆盖生产启动后最常见的初始化路径，例如配置读取、连接池初始化和首批请求涉及的类。不要把一次偶然的管理操作当成唯一工作负载，否则缓存可能偏向不常用的路径。训练结束后，重点产物是 app.aotconfig；它描述了下一步组装需要的历史和统计信息。

用配置文件组装可交付的 AOT 缓存

组装阶段读取训练配置，生成真正供生产运行加载的 .aot 文件。这个阶段的重点是固定输入：同一份应用包、同一个 JDK、同一个目标操作系统和 CPU 架构应当共同决定缓存版本。

# 组装阶段只根据训练配置写入缓存，不把它当作一次业务启动
java \
  -XX:AOTMode=create \
  -XX:AOTConfiguration=build/aot/app.aotconfig \
  -XX:AOTCacheOutput=build/aot/app.aot \
  -jar app.jar

可以把 app.aot 看成发布物的一部分，但不要跨环境随意复用。官方 Java 命令文档明确指出，AOT 缓存与特定应用、JDK 发行版、操作系统和 CPU 架构绑定；应用入口、JDK 小版本、容器基础镜像或架构变化后，应把缓存视为过期产物。

生产启动时怎样加载对象缓存

生产阶段只需要告诉 JVM 使用已经组装好的缓存。为了让部署脚本清楚表达意图，可以显式写出 AOTMode=on；也可以使用默认的 auto，让 JVM 在缓存可加载时使用它，否则按无 AOT 缓存的方式启动。

# 生产启动显式加载与当前应用和 JDK 匹配的缓存
java \
  -XX:AOTMode=on \
  -XX:AOTCache=build/aot/app.aot \
  -jar app.jar

对容器部署，建议把缓存放进与应用版本绑定的目录，而不是写入共享可变目录。回滚应用时同步回滚缓存；如果只回滚 JAR、不回滚 AOT 文件，缓存的应用签名和类布局可能不再匹配。若使用 auto，缓存不存在或不能加载时可以回到普通启动路径，但发布脚本仍应记录本次构建是否生成了匹配产物。

缓存加载失败时先检查四个绑定条件

AOT 缓存是优化产物，不能保证与所有 JVM 选项组合兼容。遇到缓存无法加载或启动行为异常时，先把问题分成以下四层：

1. 应用是否相同：确认 -jar、-classpath 或模块路径对应的应用没有更换。
2. JDK 是否相同：不要只比较主版本，构建机与运行机的 JDK 发行版和补丁版本也应纳入缓存键。
3. 平台是否相同：操作系统和 CPU 架构变化时，直接重建缓存，不把跨架构复制当成优化。
4. JVM 选项是否改变：某些 JVMTI 或其它不兼容选项会让缓存无法使用，先对照训练和生产的启动参数。

如果只是想安全回退，可以临时关闭 AOT，让应用先恢复普通启动；修复构建输入后再生成新缓存。不要为了“继续使用旧缓存”强行修改生产参数去迁就不匹配的产物。

# 排障时临时关闭 AOT，保留同一应用包观察普通启动路径
java \
  -XX:AOTMode=off \
  -jar app.jar

把 AOT 缓存纳入发布流程

一个可维护的目录可以按应用版本和平台拆分，例如 build/aot/jdk26-linux-amd64/。发布流水线先用固定的代表性工作负载训练，再由同一构建环境组装，最后把 JAR 与 .aot 一起打包。运行时只读取与当前发布坐标完全匹配的缓存。

不要把 AOT 缓存当成必须成功的业务依赖：它的职责是减少启动工作，缓存失配时应有普通启动或快速重建路径。评估收益时，比较的是同一应用、同一平台、同一启动参数下的启动与预热变化，而不是拿不同机器的单次时间直接下结论。

常见问题

JEP 516 是不是把 Java 对象永久保存到磁盘？

不是。它保存的是可在运行时重新物化的归档对象关系，JVM 仍会按当前 GC 的方式建立运行时对象。

换成 ZGC 后是否一定有启动收益？

JEP 516 让对象缓存可以覆盖包括 ZGC 在内的 GC，但收益大小仍取决于应用启动路径、训练覆盖和其它 JVM 选项，不能把兼容性改进等同于固定倍数的加速。

为什么更新一个 JAR 后旧缓存不能继续用？

AOT 缓存绑定具体应用内容；应用类路径、JDK、操作系统或 CPU 架构变化都可能破坏训练与生产的一致性，应重新训练或至少重新组装。

生产环境应该用 on 还是 auto？

缓存由发布流程严格管理时可以用 on，这样失配更容易暴露；需要保留普通启动兜底时可用默认的 auto，但仍应把缓存构建和版本绑定做好。

参考：https://openjdk.org/jeps/516；https://docs.oracle.com/en/java/javase/26/migrate/significant-changes-jdk-26-release.html；https://docs.oracle.com/en/java/javase/26/docs/specs/man/java.html。