吞吐量优先应选Parallel GC，因其专为最大化吞吐量设计，全程STW但效率高、无协调开销；G1GC仅在兼顾吞吐与软实时停顿（≤200ms）时才适用。
Java 垃圾回收（GC）策略的选择，核心取决于应用的业务特征：如果系统更看重单位时间内完成的任务量（比如批处理、后台计算），就选吞吐量优先；如果更在意单次请求的延迟稳定性（比如 Web API、实时交易），就选响应时间优先。JVM 提供的垃圾收集器和参数组合，本质上是在这两者之间做权衡。
吞吐量优先：适合 CPU 密集、可容忍暂停的场景
目标是最大化应用运行时间占比（即最小化 GC 时间），适合后台任务、数据处理、科学计算等对延迟不敏感但追求总处理量的场景。默认的 G1（在 JDK 9+ 中默认）或 Parallel GC（也称吞吐量收集器）是典型选择。
- 使用 -XX:+UseParallelGC 显式启用 Parallel GC（JDK 8 默认，JDK 9+ 需手动指定）
- 通过 -XX:MaxGCPauseMillis 设置目标停顿时间（仅作参考，Parallel GC 不严格保证）
- 用 -XX:GCTimeRatio 控制 GC 时间占比（如设为 99 表示期望 99% 时间用于应用执行，1% 用于 GC）
- 避免过度调小堆内存——吞吐量优先通常倾向较大堆 + 较少但较长的 GC 暂停
响应时间优先：适合低延迟、高交互性服务
目标是控制 GC 暂停时间上限，并提升停顿分布的可预测性，适用于金融接口、游戏服务器、实时推荐等对 P99/P999 延迟敏感的系统。
- G1 GC 是 JDK 9+ 默认，支持软实时目标：-XX:+UseG1GC + -XX:MaxGCPauseMillis=200（建议值 200–500ms）
- 若需更严苛的亚毫秒级停顿（如 ZGC（JDK 11+）或 Shenandoah（JDK 12+），启用方式分别为 -XX:+UseZGC 或 -XX:+UseShenandoahGC
- 响应时间优先时，堆不宜过大（ZGC/Shenandoah 可支持大堆，但 G1 建议 4–16GB 以平衡停顿与频率）
- 配合 -XX:+UnlockExperimentalVMOptions（ZGC 初期需此参数，JDK 15+ 已无需）和合理元空间、直接内存配置，减少非堆引发的 STW
别只看收集器名字，关键看实际行为
同一个收集器在不同参数下表现差异很大。例如 G1 在 MaxGCPauseMillis 设得过低时，可能频繁并发周期 + 多次 Mixed GC，反而降低吞吐；设得过高则退化为类似吞吐量模式。真实效果必须结合监控验证：
立即学习“Java免费学习笔记（深入）”；
- 用 -Xlog:gc*:file=gc.log:time,tags,level（JDK 9+）或 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）采集日志
- 关注指标：单次 GC 停顿时长（特别是 Full GC）、GC 频率、晋升失败（Promotion Failure）、并发模式失败（Concurrent Mode Failure）
- 工具辅助：JFR（Java Flight Recorder）、GCViewer、Prometheus + jvm_gc_collection_seconds_count
混合策略：生产环境常需动态调整
没有一劳永逸的“最优”配置。流量峰谷、数据特征变化（如缓存命中率下降导致对象创建激增）都可能让原有 GC 策略失效。
- 上线前做压测：模拟峰值 QPS + 实际数据分布，观察 GC 行为是否符合预期
- 灰度发布时开启 GC 日志对比，重点关注 P95 停顿和 GC 吞吐率变化
- 部分场景可分层治理：核心交易链路用 ZGC，后台异步任务用 Parallel GC，通过不同 JVM 实例隔离
- 注意 JVM 版本差异——JDK 17 的 G1 已显著优化转移失败处理，而 JDK 8 的 G1 缺乏很多现代特性
