吞吐量优先应选parallel gc，因其专为最大化吞吐量设计，全程stw但效率高、无协调开销；g1gc仅在兼顾吞吐与软实时停顿（≤200ms）时才适用。
选垃圾回收器不是挑参数，而是匹配业务真实需求——吞吐量、停顿时间、堆大小、CPU资源这四点定调，其余都是微调。
看业务类型：吞吐量优先还是延迟敏感？
这是最根本的判断起点。两类场景几乎不重叠：
- 后台批处理类（日志分析、报表生成、ETL）：允许秒级停顿，追求单位时间完成更多任务 → 优先考虑 Parallel GC 或 G1（开启吞吐量模式）；
- 在线交互类（API网关、支付接口、实时消息推送）：用户感知明显，STW 超过 50ms 就可能触发重试或超时 → 必须倾向 CMS（JDK8/9）、G1（合理调参）、ZGC 或 Shenandoah。
看堆内存规模：小堆、中堆、大堆走不同路径
堆大小直接影响回收器可行性：
- ≤ 2GB：Serial GC 完全够用，单线程无开销，启动快、内存占用极低；
-
2GB–16GB：Parallel GC 和 G1 是主力。Parallel 更稳、更省资源；G1 更灵活，支持暂停时间目标（
-XX:MaxGCPauseMillis=200），适合对停顿有明确约束的中型服务； - > 16GB（尤其 ≥ 32GB）：CMS 已淘汰，ZGC 成首选——它在 64GB 堆下仍能稳定控制 STW 在 10ms 内；Shenandoah 次之；G1 在此规模下容易出现长暂停或 Mixed GC 波动。
看运行环境：CPU、OS 和 JDK 版本不能忽略
再好的回收器，跑在不匹配的环境里也白搭：
- CPU 核心数少（≤ 4）：并行类回收器（Parallel、G1）收益有限，反而可能因线程竞争拖慢；Serial 或 ZGC（并发线程可控）更合适；
-
容器化部署（如 Docker）：注意 JVM 无法自动识别 cgroup 限制（尤其 JDK8），需显式配置
-XX:+UseContainerSupport+-XX:InitialRAMPercentage等参数，否则 G1/ZGC 可能误判可用内存； - JDK 版本决定选项上限：JDK 8 只能用 Serial/Parallel/CMS；JDK 11+ 才支持 ZGC（生产可用）；JDK 17+ 推荐 ZGC 或 Shenandoah；JDK 21+ 默认 G1，但 ZGC 已全面成熟。
性能测试要测什么？别只看平均值
压测时盯紧三类指标，缺一不可：
- STW 分布：不是平均暂停时间，而是 P90/P99/最大值 —— 一次 2s 的 Full GC 可能比十次 50ms 的 Minor GC 更致命；
-
GC 频率与回收效率：关注
gc.time占比（吞吐量）和gc.count（是否频繁触发）；老年代持续增长却很少回收，说明晋升策略或回收器不匹配； - 应用侧影响：结合业务指标看——TPS 是否波动？错误率是否突增？下游超时是否关联 GC 时间戳？光看 GC 日志容易误判。
