AppCDS可显著优化Java冷启动：启动时间从8.2秒降至5.1秒，类加载数由3156减至1243，初始堆内存从180MB降至135MB，核心收益在ApplicationClasses阶段的类解析与元空间分配。
直接看启动时间下降多少、类加载数量减了多少、内存 footprint 是否变小——这三个数字不拉出来对比，AppCDS 的效果就是空谈。
用 Startup Profiler 采集各阶段耗时（JDK 17+）
这是最干净、最贴近真实启动路径的测量方式。它能拆出 VMInit、ApplicationClasses、MainMethod 等关键阶段，避免被日志打点误差或首帧渲染干扰。
- 启用命令：
java -XX:+StartupProfiler -XX:StartUpLogFile=startup.log -jar app.jar - 对比重点看
ApplicationClasses阶段：AppCDS 主要省的就是这部分 —— 类解析、常量池填充、元空间分配 - 注意：必须在相同 JVM 版本、相同 GC 参数、相同硬件环境下跑两次（有/无 AppCDS），否则
VMInit波动会掩盖真实收益
用 jcmd 和 jstat 验证类加载行为是否变化
AppCDS 是否生效，不能只信日志里那句 Using shared archive，得看运行时类加载器实际干了什么。
- 启动后立即执行：
jcmd <pid> VM.native_memory summary scale=MB，重点关注class区域的 committed 值 —— 启用 AppCDS 后通常下降 20–40 MB - 再查类加载统计：
jstat -class <pid>，对比loaded和shared loaded两列：shared loaded> 0 才算真正命中归档；如果为 0，说明归档没加载或路径/版本不匹配 - 常见假阳性：
UseSharedSpaces: Unable to map shared spaces这类错误不会中断启动，但会导致 AppCDS 完全失效，需检查 JVM 日志开头几行
生成归档时必须复现“典型启动路径”
AppCDS 归档内容取决于你记录类列表时的执行路径 —— 跑一个空 main() 或只初始化 Spring Boot 的 ApplicationContext，和跑完整登录流程加载全部模块，产生的 .jsa 文件大小和覆盖范围天差地别。
- 推荐做法：在 CI 流水线中，用和线上一致的配置（profile、feature flag、DB 连接串 mock）启动一次完整业务流程，再生成归档
- 避免踩坑：
-XX:DumpLoadedClassList记录的是“实际加载的类”，不是“classpath 里所有类”。如果归档生成时跳过了某个条件分支里的类（比如某 SDK 因开关关闭没加载），运行时打开开关就会触发 fallback 加载，破坏共享效果 - 验证方法：用
java -Xshare:check -XX:SharedArchiveFile=app.jsa -cp app.jar快速校验归档可用性，失败时会明确报出缺失类或路径问题
最容易被忽略的一点：AppCDS 对启动时间的压缩集中在前 1–2 秒，后续耗时（如 Spring 初始化 Bean、数据库连接池 warmup）完全不受影响。如果你的冷启动总耗时 8 秒，其中 6 秒花在 DB 连接上，就算 AppCDS 把类加载从 1200ms 降到 400ms，用户也感知不到明显变化——得先确认瓶颈真正在类加载环节。
