Java 25 AOT 方法画像怎么验收：训练运行、缓存生成与生产边界

同一个 Java 服务在本地启动很快，换到生产机器却要等一段时间才进入稳定状态，常见原因不是业务代码突然变慢，而是 JVM 需要在当前进程里重新收集方法运行画像。Java 25 把 Ahead-of-Time Method Profiling 纳入运行时改进，并把 AOT 配置与缓存的命令行边界讲得更清楚，适合拿来做启动和预热链路的专项验收。

AOT 方法画像的核心不是“生成一个缓存文件就一定更快”，而是用与生产足够接近的训练负载记录常用方法，再在相同应用、JDK、操作系统和 CPU 条件下加载。四个条件有变化，就应重新训练或把它当作普通 JVM 启动。

先把 AOT 方法画像和普通编译分开

JIT 编译依赖当前进程的运行情况：方法被调用后，JVM 根据热点逐步优化。AOT Method Profiling 的思路是把一次代表性训练中收集到的方法运行画像提前带进后续启动，让编译器在更早阶段获得参考信息。图中的 Training Run 代表这次训练输入，它优化的是启动与预热体验，不是把所有 Java 方法都提前变成固定机器码。

Java 25 的官方迁移说明把 AOT 能力拆成命令行易用性和方法画像两部分。实践中最容易混淆的是：AOT 配置文件描述训练阶段收集的统计信息，AOT 缓存文件保存供后续 JVM 使用的优化产物。缺少配置文件时，不能直接凭一个空缓存推断训练有效。

三种 AOT 模式对应三种文件职责

可以把命令行理解为一条固定的文件链路：训练阶段获得配置，组装阶段读取配置，生产阶段尝试加载缓存。下面的示例使用一个已经编译好的 DemoApp，重点是参数职责，不要求把业务代码改造成 AOT 专用版本。

用最小命令完成一次训练和组装

先准备稳定的 classpath、JDK 25 和一段能覆盖主要初始化路径的负载。训练时显式保存配置文件：

java -XX:AOTMode=record \
  -XX:AOTConfiguration=app.aotconfig \
  -cp app.jar DemoApp --warmup-request

训练进程结束后，再用配置文件组装缓存。此阶段不会再次执行应用本身：

java -XX:AOTMode=create \
  -XX:AOTConfiguration=app.aotconfig \
  -XX:AOTCacheOutput=app.aot \
  -cp app.jar DemoApp

如果采用直接输出缓存的写法，也可以在训练阶段指定 -XX:AOTCacheOutput，由 JVM 完成后续组装。为了让排查更容易，我更建议先保留独立的 app.aotconfig：看到配置文件内容和生成时间，才能判断训练是否真的发生。

生产加载要验收四个绑定条件

生产启动时使用缓存：

java -XX:AOTMode=on \
  -XX:AOTCache=app.aot \
  -cp app.jar DemoApp

官方命令行文档明确了缓存的绑定关系：图中的 Application、AOT Cache 和 JDK/OS/CPU 分别对应应用表达、缓存文件与运行环境。它们共同决定特定应用表达方式（例如 classpath、jar 或 module-path）、特定 JDK 版本、特定操作系统和 CPU 架构能否匹配。图中的 Compatibility Boundary 就是这组条件的验收边界；只把 app.aot 从构建机复制到另一种 CPU 的机器，不能算有效部署。

验收时至少做三组对照：不加载缓存的冷启动、加载缓存的冷启动，以及加载缓存后的前几轮真实请求。记录进程就绪时间、第一批请求延迟和功能测试结果。若缓存不存在、不可读或 JVM 选项不兼容，重点是确认应用仍能正常启动并记录回退原因，而不是把回退误报成业务故障。

哪些场景应该重新训练

下面几类变化会让旧画像失去参考价值：

• classpath、jar 内容、模块路径或启动参数发生变化，导致“同一个应用”的表达已经不同。
• JDK 小版本、操作系统或 CPU 架构变化，缓存加载条件不再一致。
• 训练负载只覆盖健康检查，没有走到真实的配置读取、连接池初始化或首个业务请求。
• 生产启动参数与训练阶段不同，尤其是会改变类加载、代理或诊断行为的选项。

因此，AOT 不应成为发布包里永久携带的黑盒文件。更稳妥的做法是把 app.aotconfig、app.aot 和对应的 JDK/系统信息一起登记；每次版本发布只在对照结果成立时替换缓存，失败则回退到无缓存启动。

相关问题

AOT Method Profiling 是不是 GraalVM Native Image

不是。它是 HotSpot JVM 的 AOT 优化链路，仍然以 Java 应用和 JVM 方式启动；Native Image 是另一套构建与运行模型，不能把两者的参数混用。

只生成 app.aot 不运行压测可以吗

不建议。缓存文件存在只能说明组装动作完成，不能说明画像覆盖了关键启动路径。至少要用接近生产的初始化和首批请求做一次前后对照。

缓存加载失败会不会直接导致服务不可用

不一定。AOT 是优化能力，官方文档列出的不兼容条件通常会让缓存无法加载；应验证 JVM 是否安全回退到普通启动，并把具体原因纳入发布日志。

把“更快”改成可复查的发布条件

Java 25 的 AOT 方法画像适合解决冷启动和预热阶段的确定性问题，但收益取决于训练样本和运行环境的一致性。发布前保留三份证据：训练配置、缓存与环境指纹、两组启动和首请求对照。只有这三份证据同时成立，AOT 才是可维护的性能优化，而不是一个看起来很专业的文件副本。