Java G1 混合回收暂停的日志定位

Java G1 出现一次较长的 Mixed GC 暂停时，先不要直接修改 -XX:G1MixedGCCountTarget 或堆大小。第一步是确认日志中的事件确实是 Mixed GC，第二步再把总暂停拆成集合选择、根扫描、对象复制和收尾阶段。这样才能判断问题是在回收集合太重、引用处理耗时，还是出现了更严重的 Evacuation Failure。

官方地址：https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-g1-garbage-collector.html

定位 G1 混合回收暂停的关键，不是寻找一条“最长日志”，而是把同一个 GC 事件的身份、集合、阶段和堆变化放在一起看。只有阶段证据与现象相互对应，才适合进入参数调整。

先从事件行确认 Mixed GC

G1 的 Unified Logging 通常会在一条事件行中给出 GC 编号、收集类型、回收前后堆占用以及暂停时长。示意日志可能类似下面这样：

[info][gc] GC(42) Pause Young (Mixed) 2048M->1210M(4096M) 86.4ms

这里最重要的判断点是 (Mixed)。它表示这次暂停属于 G1 的混合收集阶段，回收集合中除了年轻代区域，还可能包含一部分老年代区域。2048M->1210M 是堆占用变化，86.4ms 是这次暂停的总耗时；它们都不能单独证明哪一个阶段造成了长暂停。

如果日志只写着 Pause Young，不要因为同一时间段出现了老年代占用就把它判为 Mixed。要确认收集类型，应该回到同一个 GC 编号，查看事件文本和后续的集合选择信息。

把暂停拆成可定位的阶段

只打开 -Xlog:gc 能看到事件摘要，但不足以解释暂停内部的耗时分布。排查阶段时，可以在复现窗口暂时提高日志粒度：

# 开启 GC 摘要、阶段明细、集合选择和堆变化日志
java -Xlog:gc,gc+phases=debug,gc+ergo+cset=debug,gc+heap=info:file=gc.log:time,uptime,level,tags \
  -XX:+UseG1GC -jar app.jar

其中，gc+phases=debug 用来展开暂停内部阶段，gc+ergo+cset=debug 用来观察 G1 如何选择回收集合，gc+heap=info 用来补充堆区域变化。生产环境应结合日志量和保留策略使用，避免为了排障无限提高级别。

在阶段明细中，优先看四类信息：

• 集合准备：Pre Evacuate Collection Set 反映暂停开始时的准备与集合确定。
• 根与引用扫描：Ext Root Scanning、Code Root Scan、Scan Heap Roots 能帮助判断根集合和记忆集相关工作是否突出。
• 对象复制：Object Copy 过重时，通常要结合回收集合大小和对象存活情况继续判断。
• 收尾：Post Evacuate Collection Set 和 Reference Processing 反映引用处理、清理等收尾工作。

这里的“优先看”是排查顺序，不等于每次日志都必须包含同样的行。不同 JDK 版本、日志级别和实际事件会影响输出细节，结论应以当前事件中实际出现的阶段为准。

用集合选择和堆变化判断压力来源

当 Pause Total 偏高时，先把它和集合选择日志放在同一 GC 编号下对照。重点看三件事：

1. 本次回收集合是否包含较多老年代区域，且集合相关信息与 Mixed 事件对应。
2. 阶段耗时是否集中在 Scan Heap Roots、Object Copy 或引用处理，而不是均匀分布。
3. 回收前后的堆占用变化是否与暂停现象相符，是否出现回收收益偏低。

例如，集合选择信息较重且 Object Copy 明显突出，说明应继续核对存活对象和复制压力；如果 Scan Heap Roots 或记忆集相关阶段突出，则应关注跨区引用和 remembered set 工作；如果收尾阶段突出，则不要把问题简单归因于老年代区数量。

这些判断需要多次相邻事件作对比，单个事件只能说明“这次暂停发生了什么”，不能直接说明长期趋势。文章中的图示只表达字段和阶段关系，不代表某个应用的真实耗时。

遇到这些日志时不要混为一谈

Mixed GC 与 Full GC

Mixed GC 是 G1 空间回收阶段中的一次暂停；Full GC 则是更强的兜底路径。两者的事件文本和影响范围不同。看到长暂停时，先按事件行区分，不能把所有“堆占用下降”都叫作 Mixed。

Evacuation Failure

如果日志出现 Evacuation Failure，它是需要单独处理的信号。它可能伴随 Allocation 或 Pinned 等原因提示，说明复制阶段没有按普通路径完成。此时应保留完整的同一 GC 事件上下文，不要只截取总耗时。

Humongous 对象

大对象会占用 G1 的连续区域，可能改变可回收区域和暂停表现。遇到异常时可以结合 gc+heap=info 的区域信息判断是否存在大对象影响，但不要仅凭一次堆前后数值下结论。

并发阶段与暂停阶段

G1 的并发标记、清理等工作与 Stop-the-World 暂停不是同一个时间维度。排查暂停时要围绕同一个 GC 事件的 pause 行和 phase 行建立关联，不能把并发日志出现的时间直接当成暂停时长。

最后形成一条可复查的定位结论

建议每次排查都记录四组证据：

当四组信息能互相对应时，结论可以写成：“GC(42) 是 Mixed pause，总暂停为某值，阶段耗时主要集中在某阶段，集合选择与堆变化支持某个排查方向；还需要连续事件或应用指标确认长期影响。”这种写法把已知事实和待确认事项分开，后续才有条件讨论参数。

如果只是想开始收集证据，最小配置可以先从 -Xlog:gc,gc+phases=debug:file=gc.log:time,uptime,level,tags 开始；只有需要解释集合选择或区域压力时，再补充 gc+ergo+cset=debug 和 gc+heap=info。日志排查完成后，应恢复适合生产的级别和轮转策略。

常见延伸问题

为什么只看 GC 总耗时不够？

总耗时只能告诉你暂停影响有多大，不能告诉你时间花在集合准备、根扫描、对象复制还是引用处理。

看到 Mixed 就一定要调 G1MixedGCCountTarget 吗？

不一定。先确认长暂停对应的阶段和集合压力；如果根扫描或复制才是主要耗时，盲目改变混合回收次数可能只是转移问题。

为什么同样的参数在不同机器上日志不同？

G1 会结合堆大小、CPU 和应用对象存活情况动态选择工作量，日志级别也会改变可见细节。因此应比较同一运行环境中的连续事件，不要只复制另一台机器的单行日志。