吞吐量与停顿时间本质矛盾，调优需依业务场景权衡：Web API/交易系统重低延迟（MaxGCPauseMillis=150～200ms），批处理重高吞吐（可设400～500ms），实时流处理要求极低且稳定停顿。
Java JVM 垃圾回收的吞吐量与停顿时间本质上是一对矛盾指标，调优不是选“高吞吐”或“低延迟”其中一个，而是根据业务场景找到可接受的平衡点。关键不在于参数堆砌，而在于理解行为逻辑、观测真实数据、做有依据的取舍。
明确你的核心业务指标
不同系统对GC表现的敏感度差异极大：
- Web API 或交易系统：用户感知强，单次响应超200ms就可能触发超时或重试，应优先控制停顿时间（如 -XX:MaxGCPauseMillis=150～200），容忍少量吞吐下降；
- 批处理或离线计算任务：关注总执行耗时和资源利用率，可接受较长但较少的GC停顿（如设为 400～500ms），换取更高吞吐；
- 实时流处理或风控引擎：要求极低且稳定的停顿（
用对收集器，再谈调优
不是所有GC都支持精细的停顿控制：
- G1 GC 是当前主流选择，-XX:MaxGCPauseMillis 对它有效，且能自适应调整年轻代大小、Region扫描范围；
- Parallel GC 专注吞吐，不响应 MaxGCPauseMillis，适合后台作业；
- ZGC / Shenandoah 适用于 JDK11+ 的超低延迟场景，停顿基本稳定在10ms内，但对内存和CPU开销略高。
错误地在 Parallel GC 上设置 MaxGCPauseMillis 不会产生预期效果，只会徒增配置复杂度。
立即学习“Java免费学习笔记（深入）”；
必须配合日志与工具验证
调参后不看日志，等于没调。启动时至少加上：
-XX:+UseG1GC -XX:MaxGCPauseMillis=200<br>-Xloggc:/var/log/myapp/gc.log<br>-XX:+PrintGCDetails -XX:+PrintGCDateStamps<br>-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M
用 GCViewer 或在线工具 GCEasy 分析日志，重点看三类数据：
- 实际平均停顿时间是否落在目标区间（比如设了200ms，结果多数在350ms，说明目标过激）；
- GC频率是否明显上升（如Minor GC从每分钟3次涨到15次），这是吞吐受损的直接信号；
- 老年代增长趋势是否平缓，避免因压缩不足导致频繁Mixed GC甚至Full GC。
几个容易被忽略的关键细节
很多调优失败源于细节失控：
- 固定堆大小：-Xms 和 -Xmx 设为相同值，避免JVM动态扩容/缩容干扰GC节奏；
- 避免过度追求单次停顿：把 MaxGCPauseMillis 设成50ms，可能让G1频繁触发小规模回收，反而拉低吞吐；
- 关注对象分配速率：如果每秒新对象分配高达500MB，再好的GC也扛不住——这时该优化代码（减少临时对象、复用对象池），而非只调JVM参数；
- 区分Minor与Mixed GC影响：Young GC停顿通常很短（
