JVM Class Data Sharing怎样生成类数据归档缩短启动时间怎样在批处理代码中减少额外分配

如果 Java 批处理每天启动很多次，而且每次都要加载同一批框架类和业务类，JVM Class Data Sharing（CDS）适合做“启动阶段”的优化：把代表性运行中加载的类保存为归档，后续 JVM 直接映射归档中的类数据。它能减少启动准备时间和多个进程的共享内存占用，但不会让业务代码里的 new 自动变少。

官方资料：https://docs.oracle.com/en/java/javase/21/vm/class-data-sharing.html

批处理要不要上 CDS，先看三个约束：启动是否频繁、JDK 与 JAR 是否稳定、能否在构建阶段保存归档。稳定就做静态或动态归档；发布变化多就使用自动归档或保留普通加载回退。

先按批处理负载选归档方案

CDS 的价值主要出现在短任务、定时任务和同一台机器上并行启动多个 JVM 的场景。一个长期运行的单体进程，启动时间占总耗时很小，就不应为了归档增加发布复杂度。

这里的“减少额外分配”要拆开看：CDS 减少的是类加载和类元数据准备工作；集合扩容、临时 DTO、序列化缓冲区等业务对象仍要通过代码和数据流优化。

类路径稳定时怎样生成静态 AppCDS

静态归档适合把归档作为构建产物发布。下面假定应用类路径只有稳定的 JAR，主类为 com.example.BatchMain。

# 第一次用真实批处理入口采集实际加载到的类
java -Xshare:off \
  -XX:DumpLoadedClassList=app.classlist \
  -cp app.jar \
  com.example.BatchMain

# 根据类列表生成静态归档；归档和同一批 JAR 一起保存
java -Xshare:dump \
  -XX:SharedClassListFile=app.classlist \
  -XX:SharedArchiveFile=app.jsa \
  -cp app.jar

# 发布后优先使用归档；不匹配时允许 JVM 普通加载
java -Xshare:auto \
  -XX:SharedArchiveFile=app.jsa \
  -cp app.jar \
  com.example.BatchMain

第一条命令的关键是入口和负载要接近生产批次，不要只运行一个没有业务初始化的空启动。生成归档时，类路径应使用 JAR；运行时类路径必须与生成归档时相同或满足官方规定的前缀关系。生产默认用 auto，把 on 留给诊断，因为归档不可用时 on 会让 JVM 直接退出。

启动脚本复杂时怎样生成动态归档

如果批处理的类路径由脚本、环境变量或多个发布步骤拼接，动态归档通常更省事。一次代表性运行退出时，JVM 会把应用实际加载的类写入动态归档。

# 用一次真实批次生成动态归档，退出时写出 app-dynamic.jsa
java \
  -XX:ArchiveClassesAtExit=app-dynamic.jsa \
  -cp app.jar \
  com.example.BatchMain

# 后续启动复用动态归档；命中失败时仍可普通加载
java \
  -Xshare:auto \
  -XX:SharedArchiveFile=app-dynamic.jsa \
  -cp app.jar \
  com.example.BatchMain

动态归档少一步手工类列表，但采集运行没有走到的分支不会进入归档。生成归档的那一次还包含写盘成本，不能把它当作性能基线；应比较后续相同入口的冷启动。

若启动脚本不便修改，可以让运行中的 JVM 配合 jcmd 生成归档：

# 启动时允许 JVM 记录动态归档信息
env JAVA_TOOL_OPTIONS=-XX:+RecordDynamicDumpInfo bash app_start.sh

# 找到目标 JVM 后生成动态归档；pid 替换为真实进程号
jcmd pid VM.cds dynamic_dump app-dynamic.jsa

这种方式适合已有复杂启动包装的批处理，但需要同机、同用户权限执行 jcmd。如果只是希望归档自动创建或按 JDK 构建更新，可以使用：

# 第一次退出时创建归档，JDK 变化后按规则重新生成
java \
  -XX:+AutoCreateSharedArchive \
  -XX:SharedArchiveFile=app-auto.jsa \
  -cp app.jar \
  com.example.BatchMain

推荐的发布架构是归档随构建产物走

对大多数短批处理，我会把归档放在构建阶段而不是运行节点临时生成。构建任务使用固定 JDK 构建和完整的代表性入口，产出 app.jar、app.jsa 以及对应的构建记录；发布时把三者放入同一个不可变目录，启动脚本只读取这组文件。

# 发布目录中的 JAR 与归档来自同一次构建
APP_DIR=/opt/batch/releases/2026-11-10

# 使用同一目录内的产物，并允许不匹配时回退
java -Xshare:auto \
  -XX:SharedArchiveFile="$APP_DIR/app.jsa" \
  -cp "$APP_DIR/app.jar" \
  com.example.BatchMain

这样做的收益是选择简单：应用版本更新就连同归档一起更新，回滚也回滚整个目录。若发布系统无法保证这一点，优先用 AutoCreateSharedArchive 或只保留默认 CDS，不要让旧的 .jsa 成为唯一启动条件。

归档不生效时先查哪些风险

诊断时可以查看类加载来源，但这只是判断局部命中的证据，不等于整个应用都被归档：

# 诊断一次启动，观察类是否来自 shared objects file
java -Xshare:auto \
  -XX:SharedArchiveFile=app.jsa \
  -Xlog:class+load=info \
  -cp app.jar \
  com.example.BatchMain

如果需要做强制测试，可以暂时使用 -Xshare:on；生产启动仍建议用 auto。另外，Windows 的静态与动态归档组合路径使用分号，不能直接照搬 Linux 的冒号写法。

最后把启动优化和对象分配分开记账

上线前至少保留三组同入口数据：默认 CDS、指定应用归档、关闭 CDS。固定 JDK 构建、机器、类路径和批处理参数，记录从进程启动到第一条有效业务日志的时间；另行记录批次期间的堆分配和 GC 情况。

如果指定归档后启动几乎没有变化，先看 JDK 构建、JAR 是否被替换、采集运行是否覆盖真实入口，以及启动耗时是否主要花在网络连接或磁盘扫描。不要为了追求命中率把所有类都塞进归档。

CDS 能直接减少批处理中的对象分配吗？

不能。CDS 主要优化类数据准备和启动加载；集合容量、临时对象、序列化缓冲区和业务数据生命周期仍要单独优化。

为什么同一个 jsa 在另一台机器上可能不生效？

归档和 JDK 构建、类路径及运行条件有关。迁移机器或升级 JDK 后，应重新生成，或者让自动归档按构建版本更新。

静态归档和动态归档应该怎么选？

类路径稳定且能在构建阶段运行代表性任务时选静态归档；启动脚本复杂或希望少维护类列表时选动态归档。两者都应保留普通加载回退。

落地清单：先按启动频率判断收益，再固定 JDK 与 JAR；构建阶段生成或自动维护归档；发布时让归档随应用版本一起走；运行时使用 auto；最后把冷启动、归档命中和业务堆分配分开衡量。这样 CDS 才是可替换的启动加速资产，而不是批处理的单点依赖。