跨VM Java AppCDS Dump失效问题及CI构建最佳实践咨询

在运行应用的VM（Rocky Linux 8.6，OpenJDK 17.0.7）上按官方教程创建的AppCDS Dump可正常工作，类加载日志显示类从shared objects file加载；但在GitLab Runner VM（Rocky Linux 8.7，OpenJDK 17.0.5）创建并打包进Docker镜像的CDS Dump，在应用VM使用时失效，类从Jar包加载，且CDS日志报错：
[0.006s][info][cds] UseSharedSpaces: Required classpath entry does not exist: /builds/build/libs/app.jar

技术问询：

1. CDS Dump的创建方式及VM配置是否会影响其可用性？存在哪些要求或限制？
2. 上述类路径条目不存在的报错具体含义是什么？
3. 是否可在CI环境中提前创建AppCDS Dump供后续使用？对应的最佳实践是什么？

1. CDS Dump的创建方式及VM配置对可用性的影响、要求与限制 #

肯定会影响，核心要求和限制包括：

• JDK版本与环境一致性：CDS Dump和运行环境的JDK必须同版本、同厂商（比如都是OpenJDK 17），小版本差异（如17.0.5 vs 17.0.7）都可能引发兼容性问题——CDS依赖JVM内部类结构，小版本更新可能调整这些结构。
• 类路径绝对路径绑定：创建Dump时，JVM会记录类路径中所有Jar包的绝对路径，后续使用时这些路径必须和创建时完全一致，否则会拒绝加载Dump。
• 操作系统与架构匹配：CDS Dump和运行环境的OS版本、CPU架构必须一致（比如都是x86_64的Rocky Linux），跨OS或架构直接无法使用。
• 创建流程规范：必须用官方指定的-XX:ArchiveClassesAtExit或-XX:DumpLoadedClasses参数创建，且创建时要模拟应用正常启动的类加载流程，确保Dump包含所有需要预加载的类，否则运行时仍会从Jar加载缺失的类。

2. 类路径条目不存在报错的含义 #

这个报错直接说明：在GitLab Runner上创建CDS Dump时，Jar包的绝对路径是/builds/build/libs/app.jar，但应用VM运行时，这个CI环境的临时路径根本不存在（应用VM的Jar包路径肯定不是这个）。CDS Dump会严格校验创建时记录的所有类路径条目，只要有一个路径找不到，就会放弃使用Dump，转而从Jar加载类。

3. CI环境创建CDS Dump的可行性及最佳实践 #

完全可以在CI环境创建CDS Dump，最佳实践如下：

• 统一基础镜像：CI环境和生产/应用VM使用完全一致的基础镜像（包含OS版本、JDK版本、架构），避免版本差异导致的兼容性问题。
• 使用标准化固定路径：创建Dump时，不要用CI环境的临时绝对路径，而是将Jar包放在固定的、运行环境也会存在的路径下（比如容器内的/app/app.jar），创建和运行时统一使用这个路径。
• 模拟真实运行场景：CI中创建Dump时，要模拟应用正常启动流程（比如启动应用直到初始化完成再退出），确保Dump包含所有需要预加载的类。
• Dump与Jar包一同打包：将生成的CDS Dump文件（默认是classes.jsa）和Jar包一起打包到Docker镜像或部署包中，确保运行时能找到。
• CI内校验Dump有效性：创建完Dump后，直接在CI环境用该Dump启动应用一次，检查类加载日志确认Dump生效，避免无效Dump流入部署环节。

内容的提问来源于stack exchange，提问作者slesh