选垃圾回收器应依据业务瓶颈：吞吐量优先用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总耗时占比、最大单次停顿、老年代增长趋势——这些才是调优依据
