JVM Class Data Sharing怎样生成类数据归档缩短启动时间怎样完成一个可复用的最小示例

我第一次把 Java 服务的启动优化从“调 JVM 参数”转到 Class Data Sharing（CDS）时，最容易混淆的是：归档不是把整个应用打包成一个更快的 JAR，而是把启动阶段实际加载的类保存为 JVM 可以更快映射的共享数据。先说结论：稳定的 classpath 应用可以用一次试运行生成 classlist，再用 -Xshare:dump 写出 .jsa 归档，启动时通过 -XX:SharedArchiveFile 使用；生产环境优先保留 -Xshare:auto，让不兼容时自动回退。

官方文档：https://docs.oracle.com/en/java/javase/21/docs/specs/man/java.html

这篇只讨论 JDK 21 命令行下的 AppCDS 最小闭环：记录类、生成静态归档、指定归档启动，以及 JDK 或启动参数变化后的处理。它不把“启动更快”写成无条件承诺，实际收益仍要用自己的应用基线测量。

先看问题现场：默认 CDS 和应用归档不是一回事

JDK 通常已经带有默认 CDS 归档，-Xshare:auto 会在可用时使用它。这个默认归档主要覆盖 JDK 运行时类；AppCDS 则进一步记录应用实际用到的类。Oracle 文档还提醒，归档类会以优化后的格式存储，归档文件可能比对应 JAR 中的类数据更大，因此应围绕真实启动路径收集，而不是把所有依赖都想当然地塞进去。

我会先把边界固定为三个对象：应用 JAR 和依赖构成的 classpath、试运行输出的 classlist、最终由 JVM 读取的 app.jsa。它们之间的关系如下图所示。

动手验证：先记录一次真正加载过的类

静态 AppCDS 的第一步是让应用在关闭前把加载过的类名写入列表。下面用占位的 app.jar 和主类 com.example.Main 表示命令形态；实际项目要把它们替换成自己的启动入口，并保持后续生成归档时的 classpath 一致。

# 试运行应用，记录启动阶段真正加载过的类
java -Xshare:off \
  -XX:DumpLoadedClassList=app.classlist \
  -cp "app.jar:lib/*" \
  com.example.Main

-Xshare:off 是为了让这次记录不依赖已有共享归档；DumpLoadedClassList 只负责产出类名列表。这个命令本身不是性能结论，也不应把一次试运行当成所有流量路径的完整覆盖。若某些类只在登录、定时任务或特定请求中加载，试运行场景应尽量覆盖这些启动期分支。

定位原因：用 classlist 生成可复用的 .jsa

有了列表后，使用同一套 classpath 调用 -Xshare:dump 生成静态归档。归档文件名可以按 JDK、平台和应用版本分开管理，避免发布时把不匹配的文件误当成通用缓存。

# 使用上一阶段的类列表生成应用级静态归档
java -Xshare:dump \
  -XX:SharedClassListFile=app.classlist \
  -XX:SharedArchiveFile=app.jsa \
  -cp "app.jar:lib/*"

这里最关键的不是参数数量，而是输入关系：app.classlist 描述类，-cp 决定类从哪里解析，app.jsa 是输出文件。把归档复制到另一台机器或换成另一个 JDK 后，不能假设仍然可用；归档要和运行时、类路径以及影响类布局的关键参数一起作为发布产物管理。

修复方案：启动时指定归档，并保留自动回退

归档生成后，应用启动命令增加 -XX:SharedArchiveFile=app.jsa。生产启动一般使用默认的 -Xshare:auto，这样归档因为环境差异不能使用时，JVM 仍可按普通路径启动。-Xshare:on 更适合测试归档是否真的被接受；Oracle 文档明确提示它不应作为生产环境的常规选项。

# 生产倾向：归档可用就使用，不可用时允许 JVM 回退
java -Xshare:auto \
  -XX:SharedArchiveFile=app.jsa \
  -cp "app.jar:lib/*" \
  com.example.Main

# 诊断倾向：要求必须使用共享类数据，不能用于生产兜底
java -Xshare:on \
  -XX:SharedArchiveFile=app.jsa \
  -cp "app.jar:lib/*" \
  com.example.Main

如果只是想减少维护一次静态 classlist，也可以了解 -XX:+AutoCreateSharedArchive 这类自动创建方式；但在发布流水线里，我更愿意先把归档输入、JDK 版本和 classpath 固定下来，再明确决定是否采用自动生成。这样排查启动差异时，能知道归档到底由哪些输入产生。

验证结果：把“归档不可用”当作发布边界处理

当归档没有生效时，优先按下面的顺序对照：第一，生成归档和启动应用是否使用同一 JDK；第二，app.jar:lib/* 是否发生增删或顺序变化；第三，是否修改了会影响 JVM 类布局或启动行为的参数；第四，是否误把 -Xshare:on 带进了生产。修复后重新生成归档，比强行复用旧的 .jsa 更可靠。

常见问题

只生成 app.jsa，不改启动命令，会自动使用吗？

不会把自定义归档当成无条件自动发现。应在启动参数中通过 -XX:SharedArchiveFile 指定它，并让 -Xshare:auto 负责可用时启用。

AppCDS 能代替应用启动性能基线吗？

不能。它针对类加载和共享数据布局，启动时间还会受到磁盘、容器资源、网络连接和应用初始化逻辑影响。应在相同环境下比较启用前后的多次启动结果。

我对这套最小闭环的判断是：AppCDS 最适合作为“发布产物的一部分”来管理，而不是一条永远不变的 JVM 参数。只要把 JDK、classpath、类列表和归档文件绑定在同一个版本上下文里，遇到归档失效时就能重新生成，而不是盲目追问某个参数为什么突然不生效。