关键在于根据业务对延迟、吞吐或内存的侧重选型：响应敏感型用zgc/shenandoah（stw≤1ms），吞吐优先型用parallel gc（吞吐率≥98%），资源受限场景结合jdk版本选g1或zgc，cms已淘汰。
选 JVM 垃圾回收器，关键不是看哪个“新”或“热门”，而是看你的应用卡在哪——是卡在响应慢（停顿长），还是卡在跑得慢（吞吐低），又或是卡在内存爆了（堆大但配额紧）。不同回收器本质是在延迟、吞吐、内存开销三者之间做取舍，没有通用解，只有适配解。
看业务对停顿时间的容忍度
交易接口、实时风控、WebSocket 服务这类系统，用户感知强，P99 停顿超过 20ms 就可能引发超时或降级。CMS 已淘汰，G1 虽可控但 Mixed GC 仍可能抖动；ZGC 和 Shenandoah 是当前生产可用的亚毫秒级方案，STW 时间基本稳定在 1ms 内，适合堆大小从 4GB 到 16TB 的场景。但要注意：ZGC 要求 JDK 15+，且需开启大页支持；Shenandoah 在 OpenJDK 中默认启用，对 JDK 版本兼容性稍宽。
看任务是否追求单位时间处理量
日志归档、报表生成、离线模型训练等后台任务，不面向用户，更在意“一小时能跑完还是两小时”。Parallel Scavenge + Parallel Old 组合就是为此设计的——它不承诺停顿，但通过多线程并行压缩老年代、优化 GC 时间占比，能把吞吐量拉到 98% 以上。参数上重点调 -XX:GCTimeRatio=19（目标 GC 时间 ≤5%）和 -XX:MaxGCPauseMillis（仅作参考，不强制），避免为控制停顿牺牲吞吐。
看部署环境的资源约束
容器化微服务常被限制内存（如 1GB～2GB），CPU 核数也有限。G1 在小堆下反而不如 Parallel 稳定，Region 划分带来额外管理开销；Serial 虽简单，但单线程在多核机器上浪费资源。此时推荐 G1 配合 -XX:MaxGCPauseMillis=50 和 -XX:G1HeapRegionSize=1M（避免 Region 过多），或直接用 ZGC（JDK 17+）——它内存开销约高 15%，但在 2GB 堆内影响可控，且停顿更稳。
看 JDK 版本与运维成熟度
JDK 8 项目只能选 Parallel 或 CMS（已废弃，不建议新用）；JDK 11 默认仍是 G1，稳定、文档全、监控工具支持好，适合大多数 Web 应用过渡；JDK 17/21 才真正把 ZGC 推向生产就绪，如果团队有 GC 日志分析能力、能接受略高的 CPU 占用（读屏障开销），ZGC 是低延迟场景的务实选择。别为了“用新版本”强行升级 JDK，而忽略 GC 行为变化带来的回归风险。
