GC 基础概念与启动性能关系

要说 GC 抑制，咱们得先搞明白一件事——GC 到底是什么，为啥它跟启动性能扯上了关系。

我个人习惯把 GC 比喻成「自动打扫房间的机器人」。你写代码的时候只管往里丢对象，GC 负责在内存快满的时候把垃圾收走。听起来挺省心对吧？但问题在于，这个机器人打扫的时候，你家的电闸会被拉掉——也就是 Stop-The-World 停顿。

启动阶段，应用正在拼命加载类、初始化对象、解析配置。这时候 GC 突然跑出来扫地，所有线程都得暂停。你想想，本来几秒就能启动完，GC 多搞几次停顿，启动时间直接翻倍。我在项目中遇到过好几次，明明业务逻辑没什么问题，启动就是慢，最后定位到是 GC 在捣乱。

GC 的基本工作原理

GC 负责自动管理堆内存。开发者只管 new 对象，GC 负责回收不再使用的对象。整个过程分两步：

• 标记（Mark）：从 GC Roots 出发，遍历所有可达对象，标记存活
• 清除/整理（Sweep/Compact）：回收不可达对象，或者压缩碎片

最头疼的就是标记阶段。如果堆里对象特别多，标记就得花很长时间，导致应用停顿。启动的时候，类加载器疯狂创建对象，GC 就得频繁介入——这就是性能瓶颈。

GC 对启动性能的影响

我做一个实际的对比你就明白了。拿一个 Spring Boot 应用来说，默认的 G1 GC 在启动时大概会触发 10～20 次 Young GC，甚至几次 Full GC。每次停顿少则 10ms，多则 200ms。加在一起，启动时间可能多出 1～2 秒。

你看，光是 Full GC 就可能吃掉 1.5 秒。这还只是默认配置，如果堆较大或者类加载器有泄漏，情况更糟。我记得有一次给客户做微服务容器化，每个 Pod 启动都要 8 秒，优化后压到 3 秒——其中 GC 停顿缩短了 2 秒多。

GC 抑制的核心思路

说白了就是：启动阶段，人工干预 GC 行为，减少甚至消除停顿。但又不是简单调大堆或关掉 GC，那会导致 OOM。

主流的抑制手段有几种：

1. 预创建对象池：把启动时要用的对象提前 new 好，放进池子，避免 GC 频繁回收和重新分配
2. 禁用并发 GC 周期：比如 -XX:-UseDynamicNumberOfGCThreads 或者使用 Epsilon GC（无操作 GC）
3. 控制分配速率：通过 -XX:TLABSize 和 -XX:SurvivorRatio 减少对象晋升
4. 调整延迟启动的 GC 线程：让 GC 线程在应用初始化完成后再开始工作

你可能会问：这些操作安全吗？会不会 OutOfMemory？好问题。我的经验是，只要你在启动完成后把 GC 调回来，或者用安全的方式恢复，就没问题。我曾经在一个订单系统中，启动阶段用了 2GB 堆全部预分配，启动后立刻触发一次 Full GC 回收不需要的对象，效果相当好。

一张图看懂 GC 抑制与启动性能

什么时候该考虑 GC 抑制

不是所有应用都需要。我建议重点关注这几种场景：

• 微服务容器化：Pod 启动越快，滚动更新越流畅
• Serverless/FaaS：冷启动时间直接决定用户体验
• 多租户 JVM 共享：一个应用启动慢，拖累整个节点
• 高密度部署：启动阶段 CPU 争抢严重，GC 停顿会被放大

小结

GC 抑制的核心目标就是：让启动阶段少停、不停。具体怎么做，后面章节会挨个拆解。这里先记住一句话——GC 不是敌人，乱停才是。