-XX:MaxGCPauseMillis 是软目标而非硬限制，设为100ms不保证每次GC≤100ms；G1仅据此动态调优年轻代大小、Region回收数等以逼近目标，但高分配速率、大对象碎片、老年代晋升加速或CPU争抢时仍可能超时，且设过低（如50ms）易致GC频发、吞吐量下降30%～50%。
MaxGCPauseMillis 是软目标，不是硬限制
设置 -XX:MaxGCPauseMillis=100 并不意味着每次 GC 都会 ≤100ms。G1 仅将其作为优化方向，通过动态调整年轻代大小、Region 回收数量、并发线程数等参数去“逼近”该目标。实际停顿仍可能突破设定值，尤其在以下场景：
- 突发高对象分配速率（如秒杀流量涌入）
- 大量 Humongous Object 分配导致 Region 碎片化
- 老年代晋升加速，触发混合回收或 Full GC
- 系统 CPU 资源争抢严重，ConcGCThreads 无法及时完成并发标记
设太低会明显拖垮吞吐量
当把 MaxGCPauseMillis 压到 50ms 甚至 20ms 时，G1 为保停顿时间，会大幅缩小年轻代、提前触发混合回收、增加 GC 频率。结果是：
- CPU 时间更多花在 GC 上，应用线程执行时间被压缩
- 频繁 Young GC 导致 Eden 区来不及“养熟”对象，大量存活对象过早晋升至老年代
- 老年代压力上升，混合回收更密集，形成恶性循环
- 实测中，从 200ms 降到 50ms 可能带来 30%～50% 吞吐量下降（见 Apache Pulsar 调优案例）
如何验证它是否真起作用
不能只看 JVM 参数有没有加，得用真实指标说话。关键要看三组数据是否同步变化：
-
G1EvacuationPause的平均/99线停顿时间（用jstat -gc或 GC 日志解析） - Young GC 触发频率（单位时间内次数）是否显著上升
- 应用吞吐量（QPS、TPS）和尾部延迟（P99/P999）是否同步恶化
推荐开启详细 GC 日志：-Xlog:gc*,gc+heap=debug,gc+ergo*=trace:file=gc.log:time,tags,uptime，再用 gcviewer 或 gceasy.io 分析趋势。
业务 SLA 决定合理取值，不是越小越好
金融交易系统要求 P99 响应 MaxGCPauseMillis=20 可能勉强够用；普通 Web API P99 在 200ms 左右，设成 100 就已激进；后台批处理任务根本不用设，留默认 200 即可。重点在于：
- 先压测出当前配置下的真实 GC 停顿分布（特别是 P99.9）
- 再按业务可容忍的最差单次停顿，上浮 20%～30% 设为目标值
- 每次调参后必须回归对比吞吐量，避免“停顿降了，QPS 跌一半”的陷阱
真正难的不是设那个数字，而是判断：当停顿从 180ms 降到 110ms，但 QPS 掉了 15%，这笔账到底划不划算。
