JVM垃圾回收器怎么选？吞吐量与延迟解析

JVM垃圾回收器选型绝非简单追逐“新”或“快”，而是需紧扣业务真实需求：吞吐量优先的批处理任务应首选Parallel GC——它以高效STW换取极致吞吐，避免G1为低延迟引入的冗余开销；响应时间敏感的服务（如API网关）不能迷信MaxGCPauseMillis参数，G1的实际停顿受分配行为和配置协同影响，需结合日志与大对象策略精细调优；ZGC与Shenandoah虽宣称停顿与堆大小无关，却对运行环境、内存分配模式及配套参数极为苛刻，易在安全点同步、元空间或压缩指针等环节暴露隐性瓶颈；任何线上切换都必须通过RSS内存、并发周期取消、分配阻塞等硬指标验证，因为GC的真实代价藏在日志里、内存中和CPU缓存行为上，而非文档口号中。

吞吐量优先该选 G1GC 还是 Parallel GC？

吞吐量优先的业务（比如批处理、离线计算、后台任务），核心目标是单位时间内完成尽可能多的工作，允许单次 GC 停顿稍长。这时候 Parallel GC 通常是更直接的选择，不是因为它“老”，而是它设计目标就是最大化吞吐量。

常见错误现象：G1GC 在纯吞吐场景下反而可能拖慢整体任务完成时间——它为低延迟做优化（比如分 Region、并发标记、混合回收），但这些机制本身有开销；而 Parallel GC 全程 stop-the-world，但单次效率高、无额外协调成本。

• -XX:+UseParallelGC 开启后，默认就是吞吐量模式，无需额外调参
• 如果堆很大（>8GB）且 CPU 核心数充足（≥8），Parallel GC 的并行收集线程数（-XX:ParallelGCThreads）建议设为物理核数的 5/8，避免线程争抢
• G1GC 只在你同时有吞吐 + 软实时停顿要求（比如 ≤200ms）时才值得引入；否则别为了“新”而换

响应时间敏感服务为什么不能只看 MaxGCPauseMillis？

Web API、实时推荐、网关类服务对单次 GC 停顿极其敏感，但很多人误以为只要给 G1GC 配上 -XX:MaxGCPauseMillis=100 就万事大吉。实际中，这个参数只是 G1 的“目标”，不是保证值——它会动态调整回收区域数量和并发线程数去逼近，但不承诺达成。

容易踩的坑：MaxGCPauseMillis 设得太低（比如 50ms），会导致 G1 频繁启动并发标记、过早触发混合回收，反而增加 CPU 占用和总体 GC 频率，最终停顿更不稳定。

• 生产环境建议从 200 起步，观察 G1 Evacuation Pause 和 G1 Humongous Allocation 日志频率
• 必须配合 -XX:G1HeapRegionSize 调整大对象阈值，避免频繁的 Humongous 分配打乱回收节奏
• 开启 -XX:+PrintGCDetails -Xlog:gc*:file=gc.log，重点看每次 Pause Young (Mixed) 的实际耗时分布，而非只盯平均值

ZGC 和 Shenandoah 真的能“无视堆大小”吗？

ZGC 和 Shenandoah 的宣传常强调“停顿与堆大小无关”，这没错，但前提是：应用分配速率稳定、没有突发性大对象潮、且元空间/压缩指针等配套没拖后腿。真实业务里，它们更容易暴露在“非 GC 停顿”上——比如安全点同步延迟、类卸载卡顿、或者 java.lang.ref.Reference 处理积压。

使用场景有限制：ZGC 要求 Linux 64-bit + JDK 11+（生产建议 ≥17），Shenandoah 在 JDK 11–15 是实验特性，JDK 16+ 才默认启用。两者都不支持 UseCompressedOops 关闭时的大堆（>4TB），这点常被忽略。

• ZGC 的 -XX:+UnlockExperimentalVMOptions -XX:+UseZGC 必须成对出现，漏掉前者会直接报错
• Shenandoah 启动失败常见于 java.lang.OutOfMemoryError: Compressed class space，需同步调大 -XX:CompressedClassSpaceSize
• 两者都禁用分代（即没有年轻代/老年代概念），所以 -XX:NewRatio 等参数无效，硬设了也不生效

线上切换 GC 前必须验证的三件事

换 GC 不是改个参数重启就完事。很多团队在线上切到 G1GC 或 ZGC 后发现 RSS 内存暴涨、CPU 利用率翻倍，问题出在验证不全。

性能影响比想象中更隐蔽：G1 的并发标记线程默认占 CPU 核数的 1/4，ZGC 的着色指针需要额外内存页表映射，Shenandoah 的转发指针会增大对象头尺寸——这些都会间接影响缓存命中率和 TLB 压力。

• 压测时必须对比 RSS（而非 heap used），用 pmap -x 或 /proc//status 查 RssAnon
• 确认 GC 日志里没有持续出现 Concurrent cycle was cancelled（G1）或 Allocation Stall（ZGC），这是资源不足的明确信号
• 检查是否禁用了 -XX:-UseBiasedLocking（ZGC/Shenandoah 强制要求），否则 JVM 启动失败

GC 选型不是拼参数，而是看它在你的分配模式、停顿容忍、部署环境下的实际行为。日志不骗人，RSS 不撒谎，安全点日志比任何文档都诚实。

理论要掌握，实操不能落！以上关于《JVM垃圾回收器怎么选？吞吐量与延迟解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！