JVM 启动流程中的 GC 活动：藏在“起跑线”后的隐形杀手

不知道你有没有这种感觉：一个 Java 应用，刚点完启动按钮，看着日志一行一行蹦，心里就盼着它赶紧就绪。但偏偏有时候，它就像卡住了一样，尤其是内存稍微大一点，启动速度简直让人抓狂。

其实这个“卡顿”，很大一部分原因就是 GC 在启动阶段偷偷干了活。不信？今天我们就把 JVM 启动的“幕后”拆开看看，到底 GC 在哪里埋了雷。

启动流程概览：GC 的出场顺序

一个 JVM 进程从零到“就绪”，大致会经历这么几个环节。我用实际经验告诉你，GC 几乎在每个环节都可能插一脚。

• 类加载与验证——加载核心库（rt.jar、java.base 等），需要分配大量对象。此时堆很小，GC 很活跃。
• 初始化阶段——执行静态代码块、初始化各种线程池、缓存组件。又会创建一批对象。
• 应用自身初始化——你的 Spring 容器、连接池、配置解析，对象数量暴增，堆空间开始吃紧。
• 首次 GC 触发——当 Eden 区填满，Minor GC 就会发生。如果在 CMS 或 G1 下，还可能触发后续背景线程。

你看，启动过程本身就是一次“对象洪水”，GC 如果处理不好，启动时间直接翻倍。

启动阶段，GC 到底在忙什么？

我拿一个典型的 Spring Boot 应用举例。它启动时，仅仅加载 Bean 定义就需要创建上千个 BeanDefinition 对象，再加上注解解析、代理生成……堆里的对象像雪崩一样。

这个时候 GC 的行为很特殊：

• 频繁的 Minor GC ——因为启动初期对象生命周期极短，很多对象刚创建就死掉了，Eden 区很快就满。年轻代回收很快，但次数多了，累积停顿一样不可忽视。
• 可能触发 Full GC ——如果采用了 CMS 或 G1，且并发标记阶段碰到启动时的元空间加载，会导致“并发模式失败”而回退到 Serial Old Full GC。我在一个支付项目中就遇到过，每次重启服务要 40 秒，其中 25 秒耗在 Full GC 上。

一张图看懂 GC 在启动中的位置

哪些 GC 活动最影响启动性能？

启动阶段，GC 造成的停顿主要有两类：

GC 类型	启动期影响	实测数据（我遇到的）
Minor GC	频繁发生（1~3秒一次），累计停顿可达几秒	启动 4G 堆 + 2Cores，Minor GC 20 次，总停顿 3.2s
Full GC (Serial/Parallel)	一旦触发，停顿 0.5~2 秒，严重拖慢启动	元空间 256M 满 → Full GC 停 1.8s
CMS 并发标记	背景线程和主线程争 CPU，导致类加载变慢	CMS 并发标记阶段，启动时间增加约 12%

嗯，这里要注意：很多团队在调优时只关注稳态下的 GC 停顿，却忽视了启动初期 GC 对“起跑线”的影响。

一个真实案例：Minor GC 拖垮了 4 秒启动

我曾经参与过一个微服务网关的项目，Java 8 + G1。每次重启要 18 秒，业务方抱怨新版本上线太慢。我加了 -Xloggc 日志一分析，结果吓我一跳：启动过程中竟然发生了 34 次 Minor GC，累计停顿 5.2 秒。

原因很简单：默认 Heap 是 4G，但启动时只用了几十 MB，Eden 区太小，导致 GC 极其频繁。后来我把 -XX:NewRatio=3 调成 -XX:NewRatio=1，再配合 -XX:SurvivorRatio=8，让年轻代大一点，减少 GC 次数。结果启动时间降到了 9 秒。

GC 抑制的初步思路

既然已经看清了启动阶段 GC 的活动规律，那么抑制它的手段也就呼之欲出了。我简单列几个方向，后面章节会逐一深入：

• 增大年轻代空间——减少 Minor GC 次数，但别太大导致 Full GC 风险。
• 预分配内存——启动前通过 GC 日志分析，用 -XX:InitialHeapSize 和 -XX:MaxHeapSize 让堆一次到位。
• 推迟并发标记——针对 CMS/G1，设置 -XX:CMSInitiatingOccupancyFraction=100 或 -XX:G1HeapWastePercent=50，让 GC 在启动期间尽量“休眠”。
• 关闭不必要的 GC 日志——启动时日志本身也会产生对象，轻微影响。

当然，这些做法都有 trade-off，需要结合业务和硬件来权衡。