G1 收集器把 -XX:MaxGCPauseMillis 作为调优入口，但该参数并不是简单地在暂停时间超过目标后强制中断回收。它驱动的是 G1 内部的一套停顿时间预测模型：收集器会根据每一轮年轻代回收的实际暂停耗时、回收区域数量、对象复制成本等指标，估算下一轮回收可容纳的回收集规模。若预测值会突破目标，G1 会主动缩小 CSet，优先回收垃圾比例最高的 Region。
这种动态调整使同一个 -XX:MaxGCPauseMillis 值在不同堆布局和分配压力下产生不同结果。下面先从预测模型的数据来源和计算方式说起，再分析参数对吞吐量的双向影响，最后给出可落地的调优与验证方法。
G1 预测停顿时间模型如何工作
G1 在每次年轻代回收结束后，会记录本次停顿耗时以及回收的 Region 数量、选入 CSet 的区域类型、存活对象复制量等数据。预测模型不是简单求历史平均值，而是采用带衰减权重的统计方式，让近期停顿数据比早期数据更有影响力。这样当应用对象分配速率突然升高时，模型能较快感知到回收成本上升，并在下一轮回收前下调回收集规模。
例如，某个应用刚开始运行时每次年轻代回收停顿约 40ms，之后由于缓存预热产生大量大对象，实际停顿上升到 90ms。G1 的预测值会逐步向 90ms 靠近，如果目标设为 100ms，收集器仍然可以继续选择较多 Region；但如果目标设为 50ms，预测值已经明显超过目标，下一轮回收就会只选择极少的高收益 Region，甚至触发连续多次小范围回收。
下面的命令启动一个 4GB 堆的 G1 服务，并将停顿目标设置为 100ms。该参数是软目标，G1 会尽最大努力让年轻代和混合回收的暂停接近这个值，但不会为了硬性达标而牺牲对象分配的连续性。
java -Xms4g -Xmx4g \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-jar application.jar
预测模型的另一个重要作用是决定并发标记后的混合回收节奏。G1 在并发标记阶段统计每个 Region 的垃圾占比，并在后续混合回收中分批回收。每次混合回收能选多少 Region，正是由停顿时间模型根据目标值倒推出来的。也就是说，停顿目标设置得越小，混合回收的执行次数就越多，单次回收越轻，但总的垃圾回收周期会拉长。
吞吐量与响应延迟的平衡点
吞吐量和响应延迟在 G1 调优中通常是相互拉扯的。-XX:MaxGCPauseMillis 的默认值是 200ms。对于多数中小型 Java 服务，200ms 的暂停目标比较宽松，G1 可以一次回收更多 Region，减少 GC 总次数，因此吞吐量表现较好；但这意味着单次暂停可能接近甚至偶尔超过 200ms，不适合对响应时间敏感的系统。
如果把目标值调低到 50ms，单次暂停会明显下降，但收集器必须把回收工作拆分成更多小批次。每次回收前后都有线程切换、根扫描、记忆集维护等固定开销，这些开销不会随着 CSet 缩小而线性降低。因此，目标值过小会导致 CPU 花费在 GC 上的比例上升，应用可用计算资源下降，吞吐量随之降低。
下面用一个简单的对象分配程序模拟持续内存压力，观察不同目标值下 GC 次数的变化。该程序不断分配 2MB 字节数组，并在超过阈值后释放引用，形成周期性的垃圾。
public class AllocationPressureDemo {
public static void main(String[] args) throws Exception {
java.util.List<byte[]> buffers = new java.util.ArrayList<>();
long count = 0;
while (true) {
buffers.add(new byte[2 * 1024 * 1024]);
count++;
Thread.sleep(20);
if (count > 2000) {
buffers.clear();
count = 0;
}
}
}
}
在相同堆大小和分配速率下，把 -XX:MaxGCPauseMillis 从 200ms 调整到 50ms，通常可以看到年轻代 GC 次数显著增加，有些场景下甚至增加 40% 到 80%。如果应用本身 CPU 余量不大，这种调度成本会直接反映在请求延迟的尾部分布上，尽管单次 GC 暂停变短，但单位时间内的总暂停时间可能反而上升。
常见调优误区与验证方法
第一个误区是把停顿目标当成硬性上限，看到日志中出现 120ms 的暂停就认为参数失效。实际上 G1 只把该值作为预测目标，在堆非常大、对象复制成本极高或系统抖动严重时，单次停顿可能超过目标。正确的判断方式是关注一段时间的暂停分布，而不是单个最大暂停值。
第二个误区是只调整 -XX:MaxGCPauseMillis 而忽略堆大小。若堆过小，无论如何调低目标，应用都会频繁触发 GC，甚至出现 Full GC；若堆过大，单次年轻代回收的区域基数变大，预测模型即使缩小 CSet，也可能因为根扫描和记忆集更新开销无法继续压低暂停。合理的做法是先根据对象活跃数据和峰值内存需求设置堆大小，再逐步收紧停顿目标。
下面命令输出详细的 GC 日志，用于分析预测停顿值和实际停顿值的差异。日志包含 GC 阶段、耗时、回收区域数以及 CSet 选择结果。
java -Xms8g -Xmx8g \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-Xlog:gc*:file=gc.log:time,uptime,level,tags \
-jar application.jar
在日志中，可以关注 Pause Young (Normal) 后的耗时以及 Predicted 字段。若预测值持续低于目标但实际值频繁超限，说明模型对当前堆的回收成本估计不足，可以结合 -XX:G1HeapRegionSize 调整 Region 大小，或检查是否存在大量跨 Region 引用导致记忆集维护开销过高。
最后一个建议是把调优过程数据化。每次调整参数后，记录应用吞吐量、99 分位响应延迟、单位时间 GC 次数和总暂停时间。如果目标值从 200ms 调整到 100ms 后，99 分位延迟下降不明显，但吞吐量下降超过 10%，说明当前应用的瓶颈不在单次暂停长度，而在 CPU 竞争，此时应优先扩容或优化对象分配速率，而不是继续压低停顿目标。
G1垃圾收集器MaxGCPauseMillis停顿时间模型修改时间：2026-08-23 03:45:39