高吞吐量与低延迟在JVM中天然冲突，调优需依业务诉求划定边界：Web API等重停顿控制，离线任务重吞吐，实时流处理重停顿稳定性。
高吞吐量和低延迟在 JVM 中天然冲突，调优不是追求“既要又要”，而是根据业务真实诉求划出可接受的边界——比如电商下单接口能容忍 150ms GC 停顿，但不能接受每秒掉 3% 的请求处理能力；而夜间跑批任务可以接受单次停顿 400ms，只要总耗时缩短 20%。
先看业务到底要什么
不同系统对 GC 表现的敏感点完全不同：
-
Web API、支付网关、风控引擎：用户或上游系统直接感知停顿，99% 请求延迟需压在 200ms 内，优先控
-XX:MaxGCPauseMillis=150，哪怕吞吐略降也值得； - 离线计算、ETL 任务、报表生成：关注整体完成时间与 CPU 利用率，适合用 Parallel GC，关闭停顿目标参数，让 JVM 全力压缩 GC 总耗时；
- 实时流处理（如 Flink 作业）、内存数据库代理层：要求停顿稳定且极短（
选对收集器，参数才有意义
参数效果高度依赖 GC 算法本身：
- G1 GC 是当前最通用的选择，
-XX:MaxGCPauseMillis对它有效，它会动态调整年轻代大小和回收区域数量来逼近目标； - Parallel GC 完全不响应
MaxGCPauseMillis，设了也没用，它只认-XX:GCTimeRatio（默认 99，即 GC 时间占比 ≤1%）； - ZGC 启用后几乎不需调停顿相关参数，它的设计目标就是停顿与堆大小解耦，但要注意
-Xmx超过 16GB 时需确认是否启用-XX:+UseZGC并配足内存带宽。
堆与内存结构要配合目标来设
光调 GC 算法不够，堆配置得跟上节奏：
立即学习“Java免费学习笔记（深入）”；
-
低延迟场景：-Xms 和 -Xmx 设为相等（如
-Xms4g -Xmx4g），避免运行中扩容带来的不确定性；新生代不宜过大（-XX:NewRatio=3或直接-Xmn1g），防止 YGC 时间飙升； - 高吞吐场景：同样建议 -Xms=-Xmx，但可适当放大堆（如 8–16GB），配合 Parallel GC 的吞吐导向策略；老年代空间要留足，减少 Full GC 触发概率；
- 所有场景下，
-XX:MaxMetaspaceSize建议显式设置（如 256m），防止动态元空间扩张引发意外停顿；高并发服务还需关注线程栈，-Xss256k可在不牺牲稳定性的前提下支撑更多连接。
验证比配置更重要
调参后必须用真实流量或压测数据验证：
- 开启 GC 日志（
-Xlog:gc*:file=gc.log:time,uptime,pid,tags,level），重点看Pause Young和Pause Mixed的实际耗时与频率； - 用
jstat -gc <pid> 1s观察 GC 频率、各代使用率、GC 时间占比（理想值 ≤5%）； - 对比调优前后关键业务指标：P99 响应时间、TPS 波动幅度、Full GC 次数是否归零；
- 发现停顿超标但吞吐未升，大概率是收集器选错或堆结构失衡，而不是参数微调能解决的。
