Java 服务不仅关心峰值性能，也关心启动速度和内存占用。CDS、分层编译、类加载优化、镜像构建等技术都和启动优化有关。

1. 启动慢的常见原因

Java 应用启动慢可能来自：

• 类太多。
• 依赖扫描过重。
• Spring Bean 初始化复杂。
• 反射和注解处理多。
• JIT 预热不足。
• 配置中心、数据库、外部服务等待。
• 容器资源不足。

JVM 优化只是其中一部分，框架和业务初始化也很关键。

2. CDS 是什么

CDS（Class Data Sharing）类数据共享可以把一部分类元数据预先归档，多个 JVM 进程可以共享这些只读数据。

价值：

• 减少启动时类加载成本。
• 降低内存占用。
• 改善多 Java 进程场景的共享能力。

3. AppCDS

AppCDS 可以把应用类也纳入归档范围。

大致流程：

1. 运行应用并记录类列表。
2. 生成 CDS archive。
3. 启动时加载 archive。

具体命令随 JDK 版本和部署方式有所差异，实际使用时应以目标 JDK 文档为准。

4. 分层编译和启动

分层编译可以让应用启动初期使用较快的 C1 编译，热点稳定后再进入更强的 C2 优化。

如果只追求启动速度，可以调整编译策略，但可能牺牲峰值性能。

常见场景：

• Serverless。
• 短生命周期任务。
• 命令行工具。
• 弹性扩容频繁的服务。

5. AOT 与 Native Image

AOT（Ahead-of-Time）提前编译可以在运行前把代码编译成本地代码，减少启动时解释和 JIT 成本。

GraalVM Native Image 是常见方案之一。

优点：

• 启动快。
• 内存占用低。

代价：

• 构建更复杂。
• 反射、动态代理、JNI 等需要配置。
• 峰值性能和传统 JVM 不一定相同。
• 运行时动态能力受限。

6. 启动优化实践

建议顺序：

1. 先用日志和 profiling 找出启动耗时点。
2. 减少不必要依赖和自动配置。
3. 延迟初始化非关键组件。
4. 减少 classpath 扫描范围。
5. 评估 CDS 或 AppCDS。
6. 对极致启动场景评估 Native Image。

7. 阶段小结

启动优化不是单一 JVM 参数能解决的。CDS 可以减少类加载成本，分层编译影响启动与峰值性能平衡，Native Image 适合极致启动场景。优化前要先测量启动阶段到底慢在哪里。

8. 启动耗时拆解图

Java 进程启动
  │
  ├─ JVM 初始化
  ├─ 类加载
  ├─ 框架扫描
  ├─ Bean 创建
  ├─ 配置读取
  ├─ 外部资源连接
  ├─ JIT 预热
  └─ 服务可用

启动慢往往不是 JVM 单方面问题。Spring 应用中，自动配置、classpath 扫描、Bean 初始化和外部连接经常占大头。

9. CDS 工作流程

第一次运行或构建阶段
  │
  ├─ 收集类列表
  ├─ 生成共享归档 archive
  ▼
后续启动
  │
  ├─ 映射 archive
  ├─ 复用类元数据
  └─ 减少类加载和内存占用

CDS 对多进程部署和启动敏感场景更有价值。

10. 启动优化优先级

优先级	优化项	说明
高	减少不必要依赖	类少了，扫描和加载都少
高	延迟非关键 Bean	缩短启动关键路径
高	避免启动期外部慢调用	外部依赖会放大启动耗时
中	CDS/AppCDS	减少类加载成本
中	调整分层编译	平衡启动和峰值性能
低到高	Native Image	收益大但改造成本也大

11. Tips 快问快答

Q：CDS 能让所有应用启动快很多吗？

A：不一定。它主要减少类加载和元数据成本，如果瓶颈在外部服务或 Bean 初始化，收益有限。

Q：Native Image 是 JVM 调优吗？

A：更像是运行形态变化。它牺牲部分动态能力，换取启动速度和内存占用优势。

Q：启动慢第一步做什么？

A：做启动阶段 profiling 或日志分段，先知道时间花在哪里。

Q：分层编译会影响启动吗？

A：会。分层编译让启动阶段更快进入可运行状态，同时保留后续优化能力。