G1 GC to-space exhausted：一次 STW 从 20ms 飙到 2.3s 的根因与三步调参

结论先行：G1 GC 的 "to-space exhausted" 不是"堆不够大"，而是一次 evacuation 阶段发现连续 to-space region 不够用、被迫退化为 Full GC 的连锁反应。这篇文章复盘一次真实的 STW 毛刺排查，从"以为是堆太小"一路挖到"3.2MB 的 JSON 序列化结果触发了 humongous 分配"，给一套能直接抄的调参和预防手段。

一、现象：每天 2~3 次，STW 从 20ms 跳到 2.3s

先交代规模和数字。

• 服务：Java 17（OpenJDK 17.0.8）+ Spring Boot 3.1，16C32G 容器，JVM 堆 -Xms4g -Xmx4g（固定 4G，避免动态扩缩），G1 GC 默认参数。
• 业务：一个"报表聚合"接口，每次请求把 3 张 MySQL 表 join 后的 ~8 万行数据在内存里做透视，然后序列化成 JSON 返回。
• 现象：P50 响应 180ms，P99 约 350ms，但每天 2~3 次（集中在 10:00~11:00 和 15:00~16:00），P99 突然跳到 2.2~2.5s，持续 1~3 秒后恢复。
• 关键特征：
  • CPU 利用率峰值只有 60%（16C 只用 9.6C），排除 CPU 瓶颈；
  • MySQL 慢日志干净，Redis 无慢查询；
  • GC log 里能看到对应的 Full GC：[GC pause (G1 Evacuation Pause) (to-space exhausted)]，耗时 2.2~2.3s；
  • 同一时段无 OOM，堆使用率峰值只有 72%（2.88G / 4G）。

最迷惑的一点：堆才用了 72%，G1 为什么要 Full GC？ 按"G1 会在堆快满时做 Mixed GC"的直觉，72% 远没到触发阈值（默认 InitiatingHeapOccupancyPercent=45 早就该启动了），但偏偏是 to-space exhausted 触发的 Full GC。

打个比方：G1 的 region 就像一间间小仓库，平时搬货（copy 存活对象）都很顺畅。但突然来了一台超大的集装箱（humongous 对象），它要占好几间仓库；偏偏这几间仓库已经被零碎的小箱子塞满了，腾不出来——G1 只好喊"全体停线"（STW），把整条流水线停下来重新安排仓库。

二、根因：3.2MB 的 JSON 触发了 humongous 分配，挤占了 evacuation 空间

2.1 G1 的 region 与 humongous 对象

G1 把堆切成固定大小的 region（默认规则：堆 4G → region size = 4G/2048 = 2MB）。任何单个对象大小 ≥ region size 的 50%（即 ≥ 1MB）就被标记为 humongous 对象，它不放在普通 region 里，而是独占一个或多个连续 region。

我们的接口里，8 万行透视后的结果集用 Jackson 序列化成 byte[]，实测大小 3.2MB——是 region size（2MB）的 1.6 倍，必须独占 2 个连续 region。

2.2 to-space exhausted 的触发链条

1. 业务高峰（QPS 从 50 涨到 200），每 100ms 就有 20+ 个请求同时在做 JSON 序列化，每 100ms 产生 20+ 个 3.2MB 的 humongous 对象；
2. 这些 humongous 对象在 Young GC 后还"活着"（引用还在 handler 里），G1 在 evacuation 时需要为它们找连续 region 做 copy；
3. 但此时老年代里已经积累了之前几轮 GC 没回收掉的 humongous 对象（报表数据被缓存了 30s），它们占着连续 region，导致可分配的空闲连续 region 不足；
4. G1 的 evacuation 在 copy 到第 N 个对象时发现 to-space 用完了 → to-space exhausted → 退化为 Full GC（Serial Old 单线程，4G 堆扫一遍约 2.2s）。

2.3 为什么"堆才用了 72%"还会 Full GC

G1 的 Mixed GC 触发阈值（IHOP）看的是整个堆的占用百分比，但 to-space exhausted 看的是 evacuation 过程中可用的空闲连续 region 数量。72% 的堆使用率里，如果大量空间被 humongous 对象碎片化地占着（每个 humongous 占 2 个连续 region），那么"看起来有空闲 region"但"没有足够连续的空闲 region"——这就是 to-space exhausted 的本质：不是总量不够，是连续性不够。

三、具体做法：三步调参 + 一个代码改动

3.1 止血：调大 region size，消除 humongous 分配

# 原来：region size = 2MB（自动），3.2MB 对象占 2 个 region → humongous
# 改为：region size = 8MB，3.2MB 对象只占 1 个 region，且不再是 humongous
-XX:G1HeapRegionSize=8m

改完后 3.2MB < 8MB，不再是 humongous 对象，走普通 region 的 copy 路径，不再需要"连续 region"，to-space exhausted 概率骤降。

3.2 根治：减少大对象产生（流式序列化）

// 改前：一次性序列化 8 万行
byte[] json = objectMapper.writeValueAsBytes(fullResult); // 3.2MB，触发 humongous

// 改后：流式序列化，分 chunk 写入 Response
try (OutputStream out = response.getOutputStream()) {
    JsonGenerator gen = objectMapper.getFactory().createGenerator(out);
    gen.writeStartObject();
    for (int i = 0; i < fullResult.size(); i += 5000) {
        List<Row> chunk = fullResult.subList(i, Math.min(i + 5000, fullResult.size()));
        gen.writeObjectFieldResults("rows_" + i, chunk);
        gen.flush(); // 每次 flush 5000 行，单 chunk 约 200KB
    }
    gen.writeEndObject();
}
// 单 chunk 200KB < 1MB（humongous 阈值），彻底消除大对象

3.3 兜底：调低 IHOP，让 Mixed GC 更早介入

-XX:InitiatingHeapOccupancyPercent=35   # 默认 45，降到 35 让并发标记更早启动
-XX:G1MixedGCCountTarget=8             # 默认 8，确保 Mixed GC 分 8 轮消化

3.4 可观测：GC log 里加 to-space exhausted 告警

# 开启统一日志格式（JDK 9+）
-Xlog:gc*,gc+heap=debug:file=/var/log/gc.log:time,uptime,level,tags:filecount=5,filesize=50m

# 监控脚本（crontab 每分钟跑一次）
grep -c "to-space exhausted" /var/log/gc.log | xargs -I{} sh -c '[ {} -gt 0 ] && alert "G1 to-space exhausted detected"'

四、踩过的坑与反直觉

• 坑 1：第一反应是"堆不够，加到 8G"。 加了之后 to-space exhausted 频率从每天 2~3 次降到 1 次，但单次 STW 从 2.3s 涨到 4.1s（堆越大，Full GC 扫描越久）。教训：to-space exhausted 的解法不是"更大堆"，是"更小对象"或"更大 region"。
• 坑 2：-XX:MaxGCPauseMillis=50 是个许愿池。 很多人觉得"我设了 50ms 目标，G1 就该在 50ms 内完成"。实际上 G1 只是尽力朝这个目标走，遇到 humongous 对象或 to-space 不足时，该 Full GC 还是 Full GC，2.3s 的暂停不会因为你的 50ms 目标而缩短。
• 坑 3：调大 region size 到 16MB 后，Young GC 变慢了。 region 越大，单 region 里"短命 + 长寿"对象混得越多，copy 的存活对象越多。最终 8MB 是 4G 堆的甜点位。
• 反直觉：-Xms4g -Xmx4g 固定堆比动态堆更"安全"。 动态扩缩（-Xms2g -Xmx4g）在扩堆瞬间会触发一次 STW（OS 分配物理页 + 零填充），那次暂停比正常 GC 还长，而且不可预测。固定堆至少让你能控制"堆有多大"这个变量。

五、结论与可复用清单

结论：G1 GC 的 to-space exhausted 不是"堆不够"，而是大对象（humongous）碎片化占用了连续 region，导致 evacuation 时找不到连续 to-space。根治思路是"让对象变小"或"让 region 变大"，而不是"让堆变大"。

可复用清单（按优先级抄）：

1. 先查 GC log：grep "to-space exhausted" gc.log，确认是不是这个原因（而不是普通 Full GC）。
2. 算一下你的 region size：堆大小 / 2048（默认），如果你的业务有 > 1MB 的对象（JSON、protobuf、byte[] buffer），大概率会踩这个坑。
3. 调 -XX:G1HeapRegionSize：让最大常用对象 < region size，消除 humongous 分配。4G 堆推荐 8m，8G 堆推荐 16m。
4. 代码层消除大对象：流式序列化、分页查询、避免一次性 new byte[large]。
5. GC log 监控：to-space exhausted 出现 1 次就告警，别等 P99 飙了才发现。
6. 别迷信 -XX:MaxGCPauseMillis：它是目标不是承诺，遇到结构性问题（humongous / 碎片化）时它帮不了你。

社区里程若衡-157 那篇 Nagle/Delayed ACK 的复盘说得好："不是每个请求都触发 Nagle，只有'上一个 ACK 还没到 + 新数据是小包'才命中"——G1 的 to-space exhausted 同理：不是每次 GC 都触发，只有"humongous 对象多 + 连续 region 不足"才命中，所以它藏在 P99 里，P50 完全看不出来。