JVM G1收集器的 Mixed GC 触发阈值与停顿预测模型

理解 G1 垃圾收集器的 Mixed GC（混合垃圾回收）何时发生以及如何预测其停顿时间，是精准调优 Java 应用的关键。Mixed GC 旨在高效回收老年代中那些大部分已无用的区域，同时严格遵守设定的最大停顿时间目标。其核心机制围绕两个核心问题展开：何时触发回收 和 每次回收多少区域。

第一部分：理解基础分区与目标

G1 将整个 Java 堆划分为多个大小相等的独立区域，每个区域可以扮演不同角色（如 Eden、Survivor、Old 或 Humongous）。这种设计使得收集器可以一次只清理一部分区域，而不是整个老年代，从而更灵活地控制停顿时间。

G1 的首要设计目标是满足应用程序设定的 最大停顿时间目标（通过 -XX:MaxGCPauseMillis 参数设置）。所有回收决策都围绕此目标展开。

第二部分：Mixed GC 的触发阈值

Mixed GC 并非在每次 Young GC 后都发生。它的启动需要满足一个核心前提：后台的并发标记周期已经完成。并发标记周期的作用是识别出老年代中哪些区域的存活对象最少，即“垃圾占比最高”的区域，这些区域将在随后的 Mixed GC 中被优先回收。

1. 启动并发标记周期的阈值

并发标记周期本身由堆占用率触发。其阈值由参数 -XX:InitiatingHeapOccupancyPercent 控制，默认值为 45。

核心逻辑：当 Java 堆的整体占用率超过这个百分比时，G1 就会启动一次并发标记周期，为下一次 Mixed GC 做准备。

执行判断：

1. 在每次 GC（包括 Young GC 和 Mixed GC）之后，G1 检查当前堆使用量占整个堆空间的百分比。
2. 计算公式为：(已使用堆内存 / 堆最大内存) * 100。
3. 比较该值与 InitiatingHeapOccupancyPercent 的设定值。
4. 如果超过，则启动一次并发标记周期。

关键点：这个阈值触发的是“标记周期”，而非直接的“垃圾回收”。标记完成后，才会在下一次 Young GC 时升级为 Mixed GC，顺便回收标记出的旧区域。

2. Mixed GC 的实际触发时机

一次完整的 Mixed GC 会发生在并发标记周期完成后的下一次 Young GC。因此，可以说 Mixed GC 的触发是隐式的，它附着在满足条件的 Young GC 上。

第三部分：停顿预测模型与回收区域选择

这是 G1 的智慧所在。它如何在给定的停顿时间目标内，决定在一次 Mixed GC 中回收多少个老年代区域？答案是 停顿预测模型。

这个模型的核心是评估回收一个老年代区域所需的时间，并动态调整回收的区域数量，以确保总停顿时间不超过目标。

1. 评估单个区域回收时间

对于每个候选回收的老年代区域，G1 会预估回收它所需的时间。预估基于历史数据，主要考虑两个因素：

• 该区域的存活数据量：通过并发标记周期获得。存活对象越少，回收越快。

• 该区域的回收效率：可以用一个简单的公式理解：
  GC效率 = (可回收的字节数) / (回收该区域预计耗时)

  效率越高，意味着回收该区域“性价比”高，能在较短停顿内释放较多内存。

2. 停顿预测与区域选择流程

G1 在决定发起一次 Mixed GC 时，会遵循以下逻辑（结合了文字与公式描述）：

1. 获取约束：读取最大停顿时间目标 T_target（例如 200ms）。
2. 收集候选：列出所有由并发标记周期标记为可回收的、属于老年代的区域。这些区域通常标记为“要回收”。
3. 排序候选：按照回收效率从高到低对这些候选区域进行排序。优先回收那些能快速释放大量内存的区域。
4. 迭代选择：初始化一个变量 T_estimated（预估总耗时）为 0，一个集合 Selected 为空。
5. 逐个评估：从排序后的候选列表头部开始遍历，对于当前区域 R：
   • 预测回收 R 所需的时间 t_R。
   • 检查：如果 (T_estimated + t_R) <= T_target，则将 R 加入 Selected 集合，并更新 T_estimated = T_estimated + t_R。
   • 如果超过目标，则停止选择。
6. 执行回收：最终 Selected 集合中的区域，连同 Young 区域，将在本次 Mixed GC 中被一并回收。

停顿预测模型的简化表达：
$$ T_{estimated} = \sum_{i=1}^{N} t_i $$
其中，$N$ 是最终选择的可回收老年代区域数量，$t_i$ 是预测的回收第 $i$ 个区域所需的时间。G1 保证 $T_{estimated} \le T_{target}$。

关键影响：如果应用内存分配速率很快，导致堆占用率频繁超过 InitiatingHeapOccupancyPercent，并发标记周期和 Mixed GC 会非常频繁。如果停顿目标 T_target 设置得过严，模型可能每次只选择回收极少的几个老年代区域，导致老年代清理不及时，最终可能引发 Full GC。

第四部分：实战调优步骤

1. 设置合理的停顿目标
设定 -XX:MaxGCPauseMillis 参数。这是 G1 所有决策的基石。一个不切实际的低目标（如 10ms）会导致 G1 极度保守，回收不力。

# 设置目标停顿时间为200毫秒
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 YourApp.jar

2. 调整并发标记启动阈值
监控 GC 日志，查看并发标记周期是否过于频繁或几乎不触发。

• 如果 Mixed GC 过于频繁，尝试适当提高 -XX:InitiatingHeapOccupancyPercent 的值（如从 45 调到 50 或 60）。
• 如果出现 Full GC，考虑适当降低该值，让标记周期和 Mixed GC 更早介入。

  # 将触发并发标记的堆占用阈值设置为40%
  java -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=40 YourApp.jar

3. 分析 GC 日志以验证模型行为
开启详细 GC 日志，这是观察 G1 内部行为的最佳方式。

java -XX:+UseG1GC -Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=100M YourApp.jar

在日志中寻找如下关键信息：

• GC pause (G1 Evacuation Pause) (mixed)：确认 Mixed GC 发生。
• (to-space exhausted) 或 (to-space overflow)：如果出现，表明回收速度跟不上内存分配，是严重的警告信号。
• [Eden: ... Survivors: ... Heap: ...]：观察每次 GC 后堆各区域的大小变化。
• Heap Occupancy: ... IHOP: ...：确认实际占用率与 IHOP 阈值的关系。

4. 关注巨型对象与老年代碎片
注意，大型对象（超过区域一半大小）会被直接分配在 Humongous 区域，属于老年代。过多的巨型对象分配会快速推高堆占用率，并可能因无法在 Mixed GC 中被高效回收而引发问题。考虑优化应用以减少巨型对象的创建，或调整区域大小 -XX:G1HeapRegionSize（仅当默认值不合适时）。

5. 平衡吞吐量与延迟
G1 的设计倾向于延迟，但以吞吐量为代价。如果应用对吞吐量敏感，可以适当放宽停顿时间目标。同时，监控 GC 的总开销时间（通过日志），确保其在可接受范围内。