选垃圾收集器关键看应用对停顿和吞吐的侧重：延迟敏感型（如Web接口、实时交易）应避开Parallel/Serial，选用CMS/G1/ZGC；若STW占比超10%，则优先Parallel或G1。

选垃圾收集器不是看哪个最新，而是看你的应用到底卡在哪——是接口响应慢得像在加载网页，还是后台任务跑得不够快？关键就两点：你更怕停顿，还是更怕慢吞吐。

先看延迟敏感度

如果单次 GC 停顿直接影响用户体验（比如 Web 接口 P99 超过 200ms、实时交易系统要求毫秒级响应），那就属于延迟敏感型。这类场景必须避开 Parallel 和 Serial，它们的 STW 时间随堆增大而明显拉长。

• 目标停顿
• 目标停顿 10–200ms → 优先试 G1，尤其堆在 10–60GB 区间时平衡性最好
• 老系统且堆

再看堆大小和硬件资源

堆不是越大越好，收集器对内存规模的适应能力差异很大：

• 堆 ≤ 4GB，单核或轻量服务 → Serial GC 足够，开销小、启动快
• 堆 4–32GB，多核 CPU，兼顾稳定与低延迟 → G1 是当前最通用的选择，参数调优成熟（如 -XX:MaxGCPauseMillis=200）
• 堆 ≥ 32GB，尤其是 100GB 以上 → ZGC 优势明显，停顿时间基本不受堆大小影响，实测 1TB 堆仍能控制在 10ms 内
• 堆极大（>1TB）且对 P99 极端敏感（如高频交易）→ Shenandoah 分代版在 JDK 25 中表现更稳，P99 可压到 4–5ms

最后看业务类型和运维成本

吞吐量优先的场景（如离线报表、ETL 批处理、模型训练）根本不需要纠结停顿：

• 默认用 Parallel GC 即可，它在 JDK 8–17 的 Server 模式下就是吞吐量标杆
• 若需精细控制 GC 频率，加 -XX:MaxGCPauseMillis 反而会降低吞吐，不推荐
• 容器环境（如 Kubernetes）中堆常被限制，要留意 G1/ZGC 的额外内存开销（约 5–20% 元数据占用）

一个快速判断流程

打开 GC 日志，查三件事：

• Full GC 是否频繁（>1 次/小时？）→ 说明老年代压力大，CMS/G1/ZGC 更合适
• Minor GC 平均停顿是否 >50ms？→ 年轻代回收效率低，考虑调大 Eden 或换 G1/ZGC
• STW 总耗时占应用总运行时间比例是否 >10%？→ 吞吐受损，Parallel 或 G1 更适合