Java JDK 26 AOT 启动 怎样处理

JDK 26 应用启用 AOT 缓存后启动异常，应先分清“缓存没有被使用”和“应用本身无法启动”。固定程序包、JDK 与平台组合，检查缓存是否对应本次部署，再决定重建缓存或退回无缓存启动，不要把旧缓存不断复制到新的运行环境。

官方参数入口：https://docs.oracle.com/en/java/javase/26/docs/specs/man/java.html。本文针对 JDK 26 的 HotSpot AOT 缓存，不是原生可执行文件打包教程。下面按一个假设的排障过程展开，所有步骤是演示设计，不是已发生的事故或本机实测。

先判断影响的是优化，还是整个启动

假设团队发布了新应用包，却沿用上一批构建的缓存。启动日志出现 AOT 相关信息后，有人认为业务代码一定损坏。此时首先要保存完整命令、退出码、错误信息和制品身份，不要只截取一行带有 AOT 的日志。

建议把事件记录分成三个节点：哪次构建生成缓存、哪次部署开始使用、首次发现什么现象。每个节点都记录实际证据，不补写猜测。若无缓存时也发生相同的业务初始化异常，应转向业务配置及依赖排查，而不是把所有错误归因于优化选项。

缓存不能脱离生成它的制品组合

官方手册将 AOT 缓存限定在特定应用、JDK 发行版本及操作系统和 CPU 架构组合内；这些条件改变时需要重新生成。生产管理上还应保存完整 JDK 构建标识、应用及依赖制品标识、训练配置和运行参数，避免只记录一个“26”。

JDK 26 发布说明中的 JEP 516 扩展了对象缓存对垃圾收集器的支持，包括 ZGC。这项变化不等于缓存可以跨任意应用和平台通用，也不等于任意 JVM 参数都兼容。不要因为看见“支持任意 GC”，就删除部署制品之间的对应关系。

建议让缓存与应用包作为同一发布单元管理。缓存路径单独设置只读消费位置，生成目录由构建过程写入；不要让多个部署任务争写一个共享文件名。本文的固定文件名仅用于独立演示目录。

用一个会正常退出的程序认识训练阶段

在单独工作目录新建 AotBoundary.java。示例只创建几个字符串并计算长度，不连接网络、不写业务数据；它用正常退出结束训练，不需要后台常驻服务。这样便于区分构建过程与业务运行过程。

import java.util.List;

public class AotBoundary {
    public static void main(String[] args) {
        // 固定输入用于演示类加载，不代表真实业务训练覆盖
        var labels = List.of("north", "central", "south");
        int total = 0;
        for (String label : labels) {
            total += label.length();
        }
        // 业务输出只是演示标记，不能证明缓存已经加载
        System.out.println("labels=" + labels.size() + ", chars=" + total);
    }
}

确认 PATH 中 java、javac、jar 均来自目标 JDK 26 后，读者可在该目录执行：

# 先确认运行工具版本；不要混用另一个JDK的java
java -version
javac -version
# 编译并制作独立演示包，后续训练与启动使用同一个包
javac AotBoundary.java
jar --create --file boundary-demo.jar --main-class AotBoundary AotBoundary.class
# 普通启动作为对照，此处不携带AOT参数
java -jar boundary-demo.jar
# 执行训练并生成缓存；等待命令正常完成，不放后台
java -XX:AOTCacheOutput=boundary-demo.aot -jar boundary-demo.jar

训练会执行应用，并在装配阶段生成缓存，因此“运行一次训练命令”不是没有业务副作用的静态打包。真实服务应准备可控训练路径和正常退出方式，使用隔离数据与凭据，避免训练时发送真实通知、消费生产消息或写入正式订单。

演示训练只覆盖这个小程序实际触及的路径，不应据此声称已覆盖框架扫描或服务请求。常驻应用不能机械等待它自己退出，也不能把强制终止等同于完成了一次合格训练。

自动降级与严格失败，应分别用在什么地方？

JDK 26 手册区分自动模式与严格启用模式：自动模式在无法加载缓存时可继续无缓存执行；严格 on 模式则报错退出，适合定位兼容问题。下面两条命令用于不同目的，不要把严格诊断命令直接当作所有生产启动脚本的默认替代。

# 自动模式保留无缓存执行退路，并记录AOT日志
java -XX:AOTMode=auto -XX:AOTCache=boundary-demo.aot -Xlog:aot -jar boundary-demo.jar
# 严格模式用于隔离排查：缓存不兼容时应关注退出信息
java -XX:AOTMode=on -XX:AOTCache=boundary-demo.aot -Xlog:aot -jar boundary-demo.jar

程序能打印演示标记，不代表缓存必然生效；自动降级后业务仍可运行。反过来，严格模式退出也不代表业务包必然不可用。读者应结合日志区分两者，而不是只看控制台是否出现业务输出。

原始事故记录若没有保留模式参数，就很难解释“同一缓存为什么在两套脚本里表现不同”。先对照实际命令，再讨论策略变更，避免为排查新增的参数成为下一次误判的来源。

修复时重建匹配缓存，不掩盖根因

建议按制品对应关系处理：程序或依赖发生变化，重新准备训练和缓存；平台或 JDK 组合变化，使用目标环境对应工具重新生成；文件不可读，处理部署路径和权限。每类动作都应有对应证据，不是把所有参数一次改完。

生成新缓存应使用新的发布目录，保留旧应用和旧缓存的完整组合供回退。不要在运行中的共享缓存路径直接覆盖，也不要用临时取消诊断日志来宣告问题消失。若需要紧急恢复，应按既有发布方案切回普通启动或已知可用制品，并继续保留故障线索。

本文没有执行这些命令，不提供“启动提升多少”的数字。真实收益应在相同环境和负载下测量，且要把训练成本与发布耗时计入采用决策。

后续记录哪些信息，才能避免再次误判？

常见疑问之一是“有缓存为何还是慢”。AOT 优化不能代替数据库连接、远程依赖或业务初始化分析。另一个疑问是“是否可以省略训练”，对于定制缓存，训练内容仍决定了观察到的应用路径；小演示的成功不代表复杂服务的所有路径都被包含。

最终要把“缓存加载情况”和“业务就绪情况”分开记录。定位清楚之后再重建或降级，才能避免将一次优化配置问题扩散为不必要的业务发布变更。

参考：JDK 26 java 命令 AOT 缓存说明；JDK 26 官方发布说明。