选垃圾收集器关键看应用对停顿和吞吐的侧重：延迟敏感型（如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 更适合
