- 垃圾回收器选错了，我的Java服务内存炸了*
引言
在Java应用的性能优化中，垃圾回收器（Garbage Collector, GC）的选择往往是被忽视的一环。许多人默认使用JVM提供的默认GC（如JDK 8的Parallel GC或JDK 11的G1 GC），却忽略了应用的独特需求。我曾经在一次生产事故中深刻体会到了这一点——由于选错了垃圾回收器，我们的Java服务内存急剧飙升，最终导致频繁Full GC和服务崩溃。本文将分享这段经历，深入分析GC选型的核心逻辑，并总结如何根据应用场景选择最合适的垃圾回收器。
主体
1. 背景：事故现象与初步排查
我们的服务是一个高并发的实时数据处理系统，运行在JDK 11上，默认使用G1垃圾回收器。某次大促活动中，服务突然出现以下现象：
- 内存使用率持续攀升，最终接近
-Xmx设置的值（16GB）； - Full GC频率从每小时1-2次激增到每分钟数次；
- 服务响应时间从平均50ms飙升至数秒，最终部分节点不可用。
通过jstat -gcutil观察GC行为，发现老年代（Old Generation）占用率长期高于90%，而G1的Mixed GC几乎无法回收老年代对象。显然，GC成了瓶颈。
2. 问题根源：G1的适用场景与局限性
G1（Garbage-First）的设计目标是平衡吞吐量和延迟，适合堆内存较大（6GB以上）且对延迟敏感（如200ms以内）的应用。但其核心假设是：
- 对象分配速率适中（Young GC能及时回收短期对象）；
- 老年代对象占比不过高（Mixed GC能有效回收老年代）。
而我们的服务恰恰违背了这两点：
- 分配速率过高：实时数据处理中大量短期对象存活时间略长（1-2秒），导致存活对象过早晋升到老年代；
- 老年代占比过高：历史数据缓存（占堆50%以上）进一步挤压了老年代空间。
G1的Mixed GC依赖“标记-清理”算法，当老年代碎片化严重时，回收效率急剧下降，最终被迫触发Full GC。
3. 对比实验：Parallel GC vs. CMS vs. ZGC
我们对比了三种GC的表现（相同负载下）：
| 指标 | Parallel GC | CMS | ZGC |
|---|---|---|---|
| 吞吐量 | 高（98%） | 中（92%） | 低（85%） |
| 最大暂停时间 | 2秒（Full GC） | 200ms（并发失败时） | 10ms |
| 堆内存占用 | 低 | 中 | 高（需预留20%） |
| 老年代回收效率 | 高（压缩算法） | 中（碎片化问题） | 高（并发压缩） |
- 关键发现*：
- Parallel GC的吞吐量最高，但Full GC的停顿时间不可接受；
- CMS的并发回收降低了停顿，但老年代碎片化问题比G1更严重；
- ZGC的停顿时间极短，但吞吐量损失显著，且需要更大的堆内存。
4. 最终方案：Shenandoah GC的救场
在JDK 12中引入的Shenandoah GC成为了我们的选择。其特点包括：
- 并发压缩：与ZGC类似，但吞吐量更高（仅损失5-10%）；
- 低延迟：暂停时间与堆大小无关，通常控制在10ms内；
- 适应高分配速率：通过“Brooks指针”技术实现并发对象移动。
调整后（-XX:+UseShenandoahGC），服务表现：
- 内存占用稳定在12GB（原16GB）；
- 最大暂停时间从2秒降至8ms；
- Full GC完全消失。
5. 通用选型指南：如何选择GC？
根据应用场景选择GC的决策树：
-
堆内存<4GB：
- 低延迟需求：Serial GC（单线程）
- 高吞吐需求：Parallel GC
-
堆内存4-8GB：
- 延迟敏感（<200ms）：CMS或G1
- 吞吐优先：Parallel GC
-
堆内存>8GB：
- 延迟敏感（<10ms）：ZGC或Shenandoah
- 混合负载：G1
特殊场景：
- 大量短期对象：避免G1，优先Parallel GC或ZGC；
- 长期存活缓存：避免CMS，优先G1或Shenandoah。
总结
垃圾回收器的选择绝非“默认即最佳”。我们的案例证明，错误的GC选型可能导致内存失控、服务崩溃。理解应用的内存行为（对象分配速率、生命周期、堆占比）是选型的前提。对于现代大内存、低延迟应用，ZGC和Shenandoah等新一代回收器提供了更好的选择，但需权衡吞吐量损失。建议通过gc.log和JVM工具（如JMC、Async Profiler）持续监控GC行为，动态调整策略。
