GC抖动：从现象到本质
很多同事问我，GC抖动到底是个什么鬼？
我通常这么回答：你想象一下高速公路堵车。正常GC就像收费站正常收费，排几分钟队就过去了。GC抖动呢？就是收费站每隔几秒就关一次门，放两辆车又关一次门。每次关门时间不长，但频率高得离谱。整个路网就这么被反复打断，谁也跑不起来。
说白了，GC抖动是“频繁但不致命的停顿”。它不像Full GC那样一口气停几秒，而是每次只停几十毫秒，但每隔几秒就来一次。后台任务在这种环境下，吞吐量断崖式下跌，延迟曲线像个心电图。
GC抖动与普通GC的硬核区别
我习惯从三个维度去区分它们：停顿持续时长、触发频率、以及对业务的影响模式。下面这个表格是我在项目复盘时经常用的对照表：
| 对比维度 | 普通GC（Minor/Full） | GC抖动 |
|---|---|---|
| 停顿时长 | 几十ms～几秒，偶尔出现 | 几ms～几十ms，高频出现 |
| 触发频率 | 几分钟～几小时一次 | 每秒几次～每分钟几十次 |
| 堆占用曲线 | 锯齿明显，回收后下降幅度大 | 锯齿细密，回收后几乎没下降 |
| 典型场景 | 老年代占满、大对象分配 | 大量短生命周期对象、TLAB快速耗尽 |
| 用户感知 | 明显卡顿或超时 | 少量请求变慢，但整体还能用 |
| 根因排查难度 | 较容易（GC日志明显） | 较难（需要时序分析） |
大家注意上表最后一行的“排查难度”。我之前有个项目，线上服务RT从5ms抖到50ms，但Full GC一天才两次。翻了三天日志才发现——Young GC每1.2秒触发一次，单次暂停8ms。这就是典型的GC抖动，藏得特别深。为什么会这样？
因为普通GC的时间间隔大，日志里一眼就能看到。抖动则是频率高、幅度小，很容易被监控系统的聚合统计给平均掉。你想想看，如果监控按分钟采样，平均停顿时长才15ms，谁会认为有问题？
抖动对业务的影响——三个典型的“被坑”场景
我在做中间件性能优化时遇到过几种典型受害场景，每种都够喝一壶的。
- 场景一：高吞吐后台任务（比如日志批处理、数据清洗）
这些任务通常一个线程处理一个分片。GC抖动时，每个线程每几秒被挂起一次。看起来单次只停20ms，但任务整体完成时间从2分钟变成8分钟。吞吐损失不是叠加，是乘数的。因为每次恢复后都要重新加载缓存数据，上下文切换成本远大于停顿本身。 - 场景二：低延迟RPC调用链
后台服务虽然不直接面向用户，但内部RPC调用有超时窗口。比如A调B、B调C，每跳都设100ms超时。GC抖动让B服务每隔几秒多消耗30ms，算上网络传输和队列排队，C服务收到的请求经常超时。我碰过最夸张的一次，timeout异常每分钟暴增600次，而单个GC停顿最大才45ms。 - 场景三：真实内存泄漏的前兆
这个最阴险。我记得有一个活，线上Young GC频率从每秒2次慢慢涨到每秒8次，持续了一周。开发觉得是正常波动，直到某天OOM把节点打挂了。复盘发现那段时间有一个定时任务生成了大量byte[]缓存，引用没释放，导致Eden区填塞速度越来越快。GC抖动其实是泄漏的“早期警报”，可惜很多人没当回事。
量化维度：我个人习惯用三个指标衡量抖动伤害——
- 抖动频率：每分钟GC次数超过30次就危险
- 抖动幅度：P99停顿超过50ms且持续1分钟以上
- 抖动与业务峰值的重叠率：高峰期抖动会放大负面影响3～5倍
⚠️ 注意：千万不要以为“停顿时间短就没事”。我曾经踩过坑，线上Young GC每次只停8ms，但频率是每秒2次。每秒钟任务被中断两次，就算每次只有8ms，累积下来吞吐量损失超过15%。而且CPU因为频繁安全点同步，还白白多耗了5%～8%。
核心知识框架：一张图讲透GC抖动
为了让大家更直观地理解GC抖动的形成、特征与影响，我画了一张结构图。这张图把刚才讲的内容串了起来。
💡 个人小技巧：我每次排查抖动问题时，第一件事不是看GC日志详情，而是先看每分钟GC次数和CPU用户态占比。如果次数超过30且CPU sys升高，基本可以确认抖动。这个办法帮我在几次大型压测中提前发现了隐患。
总结几个硬指标
为了方便大家记忆，我习惯把这些判断条件放在手边的卡片上：
- 抖动定义：Young GC或Mixed GC频率 > 30次/分钟，且单次暂停 < 50ms。
- 与普通GC的核心区别：普通GC是“大出血”，抖动是“频繁抽血”。前者造成可见停顿，后者造成吞吐慢性死亡。
- 业务影响量化：后台任务吞吐量降低50%～300%，RPC超时率增加10～100倍，CPU sys额外消耗5%+。