选垃圾回收器应依据业务瓶颈：吞吐量优先用Parallel GC，延迟敏感选G1/ZGC/Shenandoah，内存受限或防碎片则选Serial/G1/ZGC；务必结合压测与GC日志验证效果。

选垃圾回收器不是挑最新或最炫的，而是看业务真正卡在哪——是等得久、跑得慢，还是内存紧。

吞吐量优先：后台任务就用Parallel GC

如果你的应用是日终结算、报表生成、离线数据清洗这类长时间运行、允许短暂卡顿的场景，目标是单位时间干最多活，那就盯住吞吐量。

• 默认启用：-XX:+UseParallelGC（JDK 8 默认，也叫吞吐量收集器）
• 调优重点：用 -XX:GCTimeRatio=99 控制 GC 时间占比 ≤1%，或设 -XX:MaxGCPauseMillis=200 给出停顿目标（不保证达成）
• 注意：它会把老年代回收做成串行，单次停顿可能达几百毫秒，不适合用户直接感知的服务

响应延迟敏感：Web服务首选G1，超高要求上ZGC或Shenandoah

API接口要100ms内返回、支付链路不能抖动？这时候STW（Stop-The-World）就是命门。

• 通用选择：G1 GC（JDK 9+ 默认），支持大堆（几十GB）、可设停顿目标（-XX:MaxGCPauseMillis=50），适合大多数在线系统
• 极致低延：ZGC（JDK 11+ 正式可用）或 Shenandoah（JDK 12+），停顿稳定在10ms以内，且基本不随堆增大而变长
• 启用ZGC需确认：堆 ≤4TB、OS和CPU支持、JVM参数加 -XX:+UseZGC

内存受限或长期稳定运行：小堆用Serial，防碎片选G1/ZGC

容器里只给512MB、网关要7×24小时不重启、嵌入式设备资源紧张——这时GC自身开销和内存整理能力比速度更重要。

• 小堆（≤1GB）且单核环境：Serial GC最轻量，-XX:+UseSerialGC，无并发开销，但STW明显
• 防碎片关键：G1和ZGC都内置压缩，能主动整理老年代，避免长期运行后因碎片触发OOM；CMS已废弃，别再用
• 容器部署必配：-XX:+UseContainerSupport（JDK 10+ 默认开启），让JVM读取cgroup限制，否则GC会误判可用内存

别跳过验证：调参前先压测，上线前看日志

理论匹配只是起点。真实对象分配速率、存活率、晋升频率，都会影响GC表现。

• 开启GC日志：-Xlog:gc*:file=gc.log:time,tags,level（JDK 11+）
• 用真实流量或JMeter模拟压测，观察Minor GC频率、Full GC是否发生、停顿是否超标
• 重点关注：GC总耗时占比、最大单次停顿、老年代增长趋势——这些才是调优依据