Java GC 日志按区域回收分析暂停原因

我第一次排查 Java GC 停顿时，最容易误判的是“堆占用高，所以这次暂停一定是老年代回收”。G1 的日志其实把原因拆在不同层次：事件行告诉你是哪一类暂停，堆行告诉你哪些区域参与了变化，阶段行才说明时间花在了哪里。按这三个层次读，通常比只看一条最长耗时更快。

官方资料：https://docs.oracle.com/en/java/javase/26/gctuning/garbage-first-garbage-collector-tuning.html

先记住一个判断顺序：先看事件类型，再看区域变化，最后用阶段耗时解释暂停。区域数量只能提示方向，不能单独证明根因。

先把日志开到能解释区域和阶段

如果只打开 -Xlog:gc，能看到暂停总时长，却不一定能回答“哪些区域拖长了这次暂停”。排查 G1 时，我会先把日志范围扩大到堆、阶段和集合集预测：

# 同时记录 GC 事件、区域摘要、阶段耗时和集合集预测
java -Xlog:gc*,gc+heap=info,gc+phases=debug,gc+ergo+cset=debug:file=gc.log:time,uptime,level,tags \
  -jar service.jar

这组参数的重点不是把日志开得越细越好，而是让同一个 GC(n) 能在多行之间对应起来。生产环境可以先按一段时间采集，再根据日志量调整级别；本文只用日志分析，不把某个停顿数字当成所有机器都适用的阈值。

先从事件行区分是哪一种暂停

事件行通常类似 GC(42) Pause Young (Normal) (G1 Evacuation Pause)，同一个编号是串起事件、堆摘要和阶段摘要的主键。先按下面的维度归类：

我会把 Evacuation Failure 当成“先解释为什么搬不动”的线索，而不是直接归因于某个对象泄漏。G1 需要把存活对象从集合区域复制到目标区域，目标空间不足、对象被固定或可回收空间不足，都可能让后续暂停变长。

用区域变化和阶段耗时锁定暂停来源

堆摘要里的 Eden regions、Survivor regions、Old regions 和 Humongous regions 要和同一编号的事件一起看。Eden 在回收后明显下降，说明年轻代对象被处理；Old 在 Mixed 事件中参与集合，说明暂停预算的一部分花在老年代区域；Humongous 数量持续偏高，则要单独关注大对象占用的区域，不能只看普通 Old。

接下来用阶段日志确认时间分布：

# 只从文本中抓取同一 GC 编号的阶段行，便于人工对照
awk '/GC\(42\)/ && /gc,phases/ { print }' gc.log
# 先看 Object Copy、Scan Heap Roots 等阶段，再回到对应的区域摘要

如果 Object Copy 占比突出，优先解释存活对象搬迁和集合大小；如果 Scan Heap Roots 或记忆集相关工作突出，再看跨区域引用和待处理卡片；如果老年代区域的预测时间明显高，说明 Mixed 集合中的 Old regions 贡献了主要暂停预算。Oracle 文档建议用 gc+ergo+cset=debug 观察年轻代和老年代区域的预测耗时，这比凭 Old 占用百分比猜测更可靠。

我会保留的四条排查习惯

• 先用 GC(n) 对齐多行日志，不把相邻事件拼成一个暂停。
• 把“堆占用变化”和“暂停耗时”分开记录，回收量大不代表停顿一定最长。
• 看到 Mixed 时额外看 Old regions 的预测时间，看到 Full GC 时额外看 evacuation failure 和 Humongous regions。
• 只有阶段耗时与区域线索一致时，才决定调小年轻代、调整暂停目标或继续查分配与存活对象。

对我来说，这种读法的价值在于先把日志翻译成“哪类区域、哪段工作、哪种暂停”，再决定是否需要调整参数。它不替代堆转储或业务对象分析，但能避免一开始就把所有长暂停都归咎于老年代。

相关问题

为什么 Old regions 变多不一定马上出现 Full GC？ G1 还会结合标记、回收集合和暂停目标分阶段回收，Old 增长只是风险信号。

只看 GC 总耗时够吗？ 不够。并发阶段可能不阻塞应用，真正影响请求延迟的是停顿区间及其阶段构成。

什么时候再看堆转储？ 当日志显示存活对象持续上升、回收后占用仍不下降，或多次 Full GC 都无法释放空间时，再把对象引用链作为下一层证据。