• 垃圾回收器选错了，我的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. 分配速率过高：实时数据处理中大量短期对象存活时间略长（1-2秒），导致存活对象过早晋升到老年代；

2. 老年代占比过高：历史数据缓存（占堆50%以上）进一步挤压了老年代空间。

G1的Mixed GC依赖“标记-清理”算法，当老年代碎片化严重时，回收效率急剧下降，最终被迫触发Full GC。

3. 对比实验：Parallel GC vs. CMS vs. ZGC

我们对比了三种GC的表现（相同负载下）：

• 关键发现*：

• 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的决策树：

1. 堆内存<4GB：

   • 低延迟需求：Serial GC（单线程）

   • 高吞吐需求：Parallel GC

2. 堆内存4-8GB：

   • 延迟敏感（<200ms）：CMS或G1

   • 吞吐优先：Parallel GC

3. 堆内存>8GB：

   • 延迟敏感（<10ms）：ZGC或Shenandoah

   • 混合负载：G1

特殊场景：

• 大量短期对象：避免G1，优先Parallel GC或ZGC；

• 长期存活缓存：避免CMS，优先G1或Shenandoah。

  ​

总结

垃圾回收器的选择绝非“默认即最佳”。我们的案例证明，错误的GC选型可能导致内存失控、服务崩溃。理解应用的内存行为（对象分配速率、生命周期、堆占比）是选型的前提。对于现代大内存、低延迟应用，ZGC和Shenandoah等新一代回收器提供了更好的选择，但需权衡吞吐量损失。建议通过gc.log和JVM工具（如JMC、Async Profiler）持续监控GC行为，动态调整策略。