垃圾回收器选错了，我的Java服务内存炸了

垃圾回收器选错了，我的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行为，动态调整策略。