多款 GC 收集器差在哪？选型你会吗？

在Java生态中，垃圾回收器（GC）的选型直接决定了应用的吞吐量、延迟和稳定性。面对Serial、Parallel、CMS、G1、ZGC、Shenandoah等多款主流GC收集器，开发者往往陷入选择困难。不同的GC算法在内存管理策略、停顿时间控制、资源消耗等方面存在显著差异，选错收集器可能导致系统卡顿甚至崩溃。本文将深入剖析主流GC的核心差异，并提供实战选型策略。

主流GC收集器全景对比

1. 经典收集器对比

Serial GC：单线程收集器，适用于客户端应用或微服务场景
Parallel GC：多线程并行收集，追求高吞吐量
CMS GC：并发标记清除，减少停顿时间但存在内存碎片

2. 新一代收集器特性

G1（Garbage-First）：
区域化内存管理（Region）
可预测的停顿时间模型
默认最大停顿时间200ms

ZGC：
亚毫秒级停顿（<10ms） 支持TB级堆内存 基于染色指针技术 Shenandoah：
并发压缩算法
与ZGC相似的低延迟特性
更早的JDK版本支持（JDK8 backport）

性能对比表格

GC选型五大黄金法则

法则1：吞吐量 vs 延迟

高吞吐优先：选择Parallel GC（JDK8）或G1（JDK11+）
低延迟优先：直接使用ZGC（JDK15+）或Shenandoah

法则2：堆内存规模

小堆（<4GB）：CMS或G1
大堆（4到64GB）：G1优先
超大堆（>64GB）：必须选择ZGC

法则3：硬件资源配置

多核CPU：G1/ZGC的并行优势更明显
内存带宽：ZGC需要高速内存支持

实战选型四步法

Step 1：确定核心指标

强制指标：
最大容忍停顿时间（P99延迟）
系统可用性要求
硬件资源预算

Step 2：环境特征分析

关键维度：
1. 并发用户量级
2. 对象存活周期分布
3. 内存分配速率
4. 系统升级成本

Step 3：版本适配检查

版本限制：
ZGC需JDK11+（生产推荐JDK17+）
Shenandoah需RedHat系JDK支持
G1从JDK9开始作为默认收集器

Step 4：渐进式验证

验证路线：
1. 测试环境压力测试
2. 监控GC日志（-Xlog:gc）
3. 使用JFR分析瓶颈
4. 灰度环境逐步验证

最佳实践案例

案例1：电商大促场景

需求特征：
高峰QPS 10万+
要求99.9%请求延迟<200ms 解决方案：
JDK17 + ZGC + 32GB堆内存
设置-XX:MaxGCPauseMillis=50

案例2：数据分析平台

需求特征：
每日处理TB级数据
允许秒级停顿
解决方案：
JDK11 + G1收集器
配置-XX:G1NewSizePercent=40

未来趋势：GC技术的演进方向

三大技术趋势：
1. 完全并发化（ZGC已实现并发压缩）
2. 硬件加速（如Intel Optane持久内存）
3. AI驱动的自适应调优（动态预测GC策略）

结论

GC收集器的选择本质上是在吞吐量、延迟、资源消耗之间寻找平衡点。对于新项目建议直接采用ZGC，其亚毫秒级停顿和TB堆内存支持已成为新一代标准。传统系统迁移时，需通过GC日志分析+压力测试验证兼容性。记住：没有最好的收集器，只有最适合业务场景的选择。