吞吐量优先与响应时间优先需依业务特征权衡：批处理类重吞吐（如Parallel GC，吞吐≥90%），交互服务重响应（如G1/ZGC，停顿≤200ms）；GC日志应关注吞吐率与P95/P99停顿；参数与堆大小是调节杠杆，内存占用影响二者平衡。
吞吐量优先和响应时间优先不是非此即彼的选择，而是根据业务特征做有依据的取舍。关键看你的应用“更怕什么”：是怕整体处理慢（吞吐低），还是怕某一次卡顿（延迟高）。
看业务类型决定主目标
后台批处理、ETL任务、离线计算类应用，用户不感知单次执行耗时，只关心一天能跑完多少作业——这类场景吞吐量优先更合理。Parallel GC（PS+PO）就是为此设计，它用较长但较少的停顿，把GC总开销压到最低，常见生产要求吞吐 ≥90%。
而电商下单、支付网关、实时风控、API网关等交互型服务，用户对“卡一下”极其敏感。一次 500ms 的 STW 就可能触发超时重试或前端报错——这类必须响应时间优先，G1（JDK8u40+）、ZGC（JDK11+）或 Shenandoah（JDK12+）才是合适选择，它们把单次停顿控制在百毫秒甚至10毫秒内。
看GC日志里的两个核心数字
分析 GC 日志时，重点盯住两组数据：
立即学习“Java免费学习笔记（深入）”；
- 吞吐量相关：统计一段时间内（如1小时）所有 GC 耗时总和，再用公式算出实际吞吐 =（总运行时间 − GC 时间）/ 总运行时间。低于90%就说明 GC 开销过大。
- 响应时间相关：关注单次 GC 的最大停顿（尤其是 Full GC）、P95/P99 停顿时间。例如 G1 日志中 [GC pause (G1 Evacuation Pause) (young), 0.182 ms] 这类数值，连续出现 >200ms 就需警惕。
参数设置体现权衡逻辑
同一个回收器也能通过参数倾斜目标：
- G1 中设置 -XX:MaxGCPauseMillis=200，是向 JVM 明确表达“宁可多收几次，也要每次别太长”。但它不是硬约束，JVM 会动态调小年轻代、增加并发线程来满足，代价是 GC 频率上升、吞吐轻微下降。
- Parallel GC 没有类似参数，但可通过 -XX:GCTimeRatio=19（即 GC 时间占总时间 ≤ 1/20 = 5%）反向控制吞吐下限，适合对停顿不敏感但对吞吐有硬指标的系统。
- 堆大小本身也是杠杆：堆设得太小，GC 频繁 → 延迟和吞吐双输；堆设得太大，单次回收扫描范围大 → Parallel GC 停顿拉长，G1/ZGC 则相对友好。
不要忽略内存占用这个隐性因素
吞吐和延迟都受内存占用影响。比如老年代长期接近 95% 使用率，哪怕用了 ZGC，也会因并发标记压力大、晋升失败而触发退化 Full GC，瞬间破坏低延迟承诺。所以 GC 日志里要同步观察 老年代使用趋势 和 对象晋升速率，而不仅是停顿时间本身。
