吞吐量优先应选 Parallel GC，因其专为最大化吞吐量设计，全程 STW 但效率高、无协调开销；G1GC 仅在兼顾吞吐与软实时停顿（≤200ms）时才适用。
吞吐量优先该选 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 <pid>或/proc/<pid>/status查RssAnon - 确认 GC 日志里没有持续出现
Concurrent cycle was cancelled（G1）或Allocation Stall（ZGC），这是资源不足的明确信号 - 检查是否禁用了
-XX:-UseBiasedLocking（ZGC/Shenandoah 强制要求），否则 JVM 启动失败
GC 选型不是拼参数，而是看它在你的分配模式、停顿容忍、部署环境下的实际行为。日志不骗人，RSS 不撒谎，安全点日志比任何文档都诚实。
