从Region到Mixed GC：首席架构师带你深入G1垃圾收集器底层与调优实战

作者： /

本文面向具有一定JVM基础的中高级工程师，旨在彻底厘清G1垃圾收集器的核心设计哲学——基于Region的内存布局，以及由此衍生出的并发标记、Mixed GC等关键机制。我们将从计算机内存管理的基本原理出发，深入到G1的写屏障、RSet、CSet等内部数据结构的实现，并最终落脚于真实世界中，如何通过分析GC日志，系统性地调优G1以满足低延迟、高吞吐的严苛要求，例如在金融交易或实时风控等场景下的应用。

现象与问题背景

在Java虚拟机技术演进的历程中，垃圾收集器（Garbage Collector, GC）一直是性能优化的核心战场。尤其是在进入大内存时代（堆内存普遍超过16GB甚至上百GB）后，传统的GC算法开始面临严峻挑战。以广受欢迎的CMS（Concurrent Mark Sweep）收集器为例，它虽然通过并发标记极大地降低了“Stop-the-World”（STW）的时间，但其固有的缺陷在高并发、大堆场景下被无限放大：

  • 内存碎片化： CMS基于“标记-清除”算法，长时间运行后，堆内存会产生大量不连续的小块空间。当应用需要分配一个大对象时，即使总的空闲内存足够，也可能因为找不到连续的空间而触发一次耗时极长的Full GC，这在延迟敏感的系统中是不可接受的。
  • Concurrent Mode Failure： CMS在并发标记期间，业务线程仍在运行并产生新的垃圾，这部分被称为“浮动垃圾”。同时，老年代的空间也在被消耗。如果在并发清理完成前，老年代没有足够的空间容纳从年轻代晋升的对象，就会触发“并发模式失败”，JVM不得不挂起所有用户线程，转而使用单线程的、STW的Serial Old收集器进行Full GC。这对性能而言是一场灾难。
  • 不可预测的停顿： 尽管CMS的并发阶段很出色，但其Initial Mark和Remark两个阶段仍然是STW的。在大堆、高并发下，Remark阶段的停顿时间可能会达到数百毫秒，足以对业务造成可感知的抖动。

正是在这样的背景下，G1（Garbage-First）收集器应运而生。它的设计目标就是为了取代CMS，成为服务端大内存应用的标准解决方案。G1的核心使命是在一个可预测的停顿时间内，高效地回收海量内存，从而根本上解决CMS带来的碎片和停顿不可控的问题。

关键原理拆解

要理解G1的精髓，我们必须回归到内存管理的第一性原理，并审视G1是如何通过创新的设计来应对这些经典挑战的。这部分，我们用一种偏学术的视角来剖析其理论基础。

Region：堆内存管理的范式革命

传统的垃圾收集器，如Serial、Parallel、CMS，都将堆内存划分为物理上连续的年轻代（Eden, Survivor）和老年代。这种划分方式直观，但在管理上缺乏灵活性。G1则彻底颠覆了这一设计，它将整个Java堆划分为多个大小相等的独立区域（Region）。每个Region的大小可以通过 -XX:G1HeapRegionSize 参数设定，取值范围为1MB到32MB，且必须是2的幂。一个G1堆理论上最多可以有2048个Region。

每个Region在逻辑上扮演着传统分代模型中的角色。它可以是Eden、Survivor或Old区。这种设计带来了几个根本性的优势：

  • 灵活的分代： 年轻代和老年代不再是物理上连续的内存块，而是一系列非连续Region的集合。这使得G1可以根据运行时的需要，动态地调整年轻代和老年代的大小，而无需进行大规模的内存移动。
  • Humongous Object处理： 对于超过Region容量一半的大对象（Humongous Object），G1会将其分配在N个连续的Region中，称为Humongous Region。这套专门的机制避免了传统GC中大对象分配对内存连续性的破坏。
  • “Garbage-First”的基石： 将堆拆分为Region，使得GC的最小回收单元从“整个分代”缩小为“一个或多个Region”。G1可以跟踪每个Region的“回收价值”（即垃圾最多、回收收益最大），并在有限的停顿时间内，优先回收那些价值最高的Region。这正是“Garbage-First”名字的由来，其背后是一种贪心算法思想的应用。

RSet：跨Region引用的解决方案

Region的独立性带来了一个新的、严峻的挑战：当回收一个Region（例如，Region A）时，我们如何知道是否有来自其他Region（例如，Region B）的引用指向了Region A中的对象？如果不知道，我们就可能错误地回收掉仍然存活的对象。在传统GC中，因为年轻代和老年代是整体回收的，这个问题主要体现在老年代对年轻代的引用上，通过一个称为“Card Table”的数据结构来解决。

G1将这一思想发扬光大，为每个Region都维护了一个名为**Remembered Set（RSet）**的数据结构。RSet记录了“谁引用了我”，即其他Region中哪些Card指向了当前Region。当进行GC时，只需扫描待回收Region的RSet，就能找到所有外部的根引用，而无需全堆扫描。

从计算机系统角度看，RSet的维护依赖于写屏障（Write Barrier）。 当应用程序执行一个引用赋值操作，如 `obj.field = p` 时，JVM会插入一段额外的代码（即写屏障）。这段代码会检查这次赋值是否产生了跨Region引用。如果是，它就会更新被引用对象所在Region的RSet。这是一个典型的空间换时间（RSet占用内存）和CPU换时间（写屏障消耗CPU）的权衡。RSet的内存开销可能占到整个堆的1%到5%，这是一个不小的代价，但它换来的是对任意Region子集进行独立、快速回收的能力。

CSet与Mixed GC：可预测停顿时间的核心

G1的停顿时间之所以可预测，其秘密武器在于它如何选择回收目标。在一次GC停顿中，G1需要回收的Region集合被称为**Collection Set（CSet）**。

  • 在**Young GC**期间，CSet包含所有Eden Region和Survivor Region。这与传统GC的Minor GC类似，采用复制算法，是完全STW的。
  • G1的革命性之处在于**Mixed GC**。在并发标记周期（稍后详述）完成之后，G1已经计算出每个Old Region的回收价值。Mixed GC的CSet不仅包含所有Young Region，还会根据用户设定的停顿时间目标（-XX:MaxGCPauseMillis），选择性地加入一部分回收价值最高的Old Region。

通过控制每次Mixed GC中Old Region的数量，G1可以将STW停顿严格控制在目标值附近。它通过一个复杂的预测模型，基于历史回收数据来估算回收一个Region所需的平均时间，从而决定在本次CSet中可以放入多少个Old Region。这种“化整为零”的策略，用多次、短暂的Mixed GC停顿，逐步回收老年代的垃圾，从而避免了CMS那种漫长的Full GC。

系统架构总览

我们可以将G1的完整工作流程看作一个状态机，它在Young GC和Mixed GC两种模式之间切换，中间穿插着一个并发标记周期。

  1. Young GC（Evacuation Pause）： 这是G1的常规工作模式。当Eden区满时，触发Young GC。这是一个并行的、完全STW的过程。存活的对象会被拷贝到Survivor区或者直接晋升到Old区。这个过程与Parallel Scavenge收集器非常相似，但作用域是Region。
  2. 并发标记周期（Concurrent Marking Cycle）： 当整个堆的占用率达到某个阈值（由 -XX:InitiatingHeapOccupancyPercent，简称IHOP，默认45%控制）时，G1会启动一个并发标记周期，为接下来的Mixed GC做准备。这个周期非常复杂，包含以下几个步骤：
    • Initial Mark（初始标记）： STW阶段。它标记了从GC Roots直接可达的对象。这个阶段通常会“借用”一次Young GC的停顿来完成，因此它的额外开销非常小。
    • Root Region Scanning（根区域扫描）： 并发阶段。扫描在Initial Mark暂停期间被标记为存活的Survivor区域，找出由这些区域指向老年代的引用，并标记被引用的老年代对象。
    • Concurrent Marking（并发标记）： 并发阶段。这是最耗时的阶段，GC线程与应用线程并发执行。GC线程从GC Roots开始遍历整个堆的对象图，寻找所有存活对象。为了处理在标记期间应用线程对对象图的修改，G1采用了SATB（Snapshot-At-The-Beginning）算法来保证标记的正确性。
    • Remark（重新标记）： STW阶段。这是最后一个标记阶段的暂停，用于处理在并发标记阶段结束后，因用户程序继续运行而导致标记变动的那一部分对象。G’1通过处理SATB日志，能高效地完成这个过程，停顿时间通常很短。
    • Cleanup（清理）： STW和并发阶段。首先，STW阶段会统计每个Region中对象的存活情况，并根据此信息对Region进行回收价值排序。然后，它会重置RSet。此阶段还会识别出完全不包含任何存活对象的Region，并将其直接回收，这是一个并发的过程。
  3. Mixed GC（Evacuation Pause）： 在并发标记周期成功完成后，G1就掌握了Old Region的垃圾状况。它会启动一轮或多轮Mixed GC。如前所述，Mixed GC会回收所有的Young Region，并根据停顿时间目标，选择性地回收一部分垃圾最多的Old Region。这个过程会持续进行，直到回收的收益低于某个阈值（由 -XX:G1HeapWastePercent 控制），G1会重新回到纯Young GC模式，等待下一次IHOP阈值被触发。

如果Mixed GC的回收速度跟不上垃圾产生的速度，导致老年代被填满，G1最终还是会触发一次后备的、单线程的、STW的Full GC，这正是我们需要通过调优极力避免的情况。

核心模块设计与实现

接下来，我们切换到极客工程师的视角，深入一些关键实现的细节和坑点。

写屏障与RSet的实现代价

G1的高效回收能力，其代价就是写屏障的开销。JVM JIT编译器在编译Java代码时，会对每一个引用类型的字段写操作（`putfield`指令）前后插入额外的指令。这被称为写屏障。


// 伪代码，示意G1的写屏障逻辑
void post_write_barrier(Object target, Object field, Object value) {
    // 1. 检查是否为null，对null的赋值不需要处理
    if (value == null) return;

    // 2. 获取引用来源和目标的Region
    Region sourceRegion = get_region(target);
    Region targetRegion = get_region(value);

    // 3. 判断是否是跨Region引用
    if (sourceRegion != targetRegion) {
        // 4. 获取value所在Region的RSet
        RememberedSet rset = targetRegion.getRSet();
        
        // 5. 将target对象所在的Card加入到RSet中
        // 这是一个异步操作，通常是放入一个本地线程的缓冲区
        // 后续由专门的线程处理这些缓冲区，更新RSet
        rset.add(get_card(target)); 
    }
}

// 业务代码: myObject.myField = anotherObject;
// JIT编译后可能变成:
pre_write_barrier(myObject, myField); // SATB需要前置屏障
myObject.myField = anotherObject;
post_write_carrier(myObject, myField, anotherObject); // RSet更新需要后置屏障

工程坑点：写屏障的开销不是零。在写密集型，特别是小对象、跨Region引用频繁的应用中（例如，一个节点引用了大量其他节点的复杂图结构），写屏障会显著消耗CPU资源，并可能成为性能瓶颈。G1通过批量处理更新请求（Dirty Card Queue）来摊销开销，但这仍然是一个需要关注的性能指标。

Evacuation Failure：一个危险的信号

在任何使用复制算法的GC停顿中（Young GC或Mixed GC），最怕的就是“Evacuation Failure”，即“疏散失败”。这意味着在拷贝存活对象时，目标区域（To-Space，可能是Survivor区或新的Old区）的空间不足以容纳所有存活对象。


[gc,promotion] 24.354: ... promo-failure(1): promotion of object of size 131088 failed
...
[gc,phases] 24.354: [Evacuation Failure]
...

极客解读：当这个日志出现时，你的JVM正在经历一次痛苦的停顿。因为无法完成拷贝，JVM不得不放弃本次复制，转而在原地对这些无法移动的对象进行整理，这个过程效率极低。对象也可能被直接“就地”晋升到老年代，即使它们的年龄还不够。频繁的Evacuation Failure会导致：

  • 停顿时间飙升： 远超你设定的 MaxGCPauseMillis。
  • 堆内存恶化： 大量本应在年轻代就被回收的对象过早进入老年代，增加了老年代的压力，可能更快地触发并发标记和Mixed GC，甚至Full GC。

导致此问题的常见原因包括：Survivor空间设置过小（虽然G1会动态调整）、应用瞬间产生大量存活对象（例如一次缓存加载）、或者堆空间整体不足。

Humongous Object的爱与恨

G1对大对象的处理是一把双刃剑。一方面，它通过专门的Humongous Region避免了大对象分配对常规Region的干扰。另一方面，Humongous Object的管理本身也充满了陷阱。

  • 分配： Humongous Object直接在老年代分配。这意味着即使是“朝生夕死”的大对象，也会直接进入老年代，增加了老年代的负担。
  • 回收： 对Humongous Region的回收，通常是在并发标记周期结束后的Cleanup阶段，或者在Full GC时进行。它们不会在常规的Mixed GC中被回收，除非它被标记为完全不存活。这导致Humongous垃圾的回收相对滞后。
  • 碎片： 如果一个Humongous Object占用了N个Region，而另一个占用了M个，它们之间可能会留下无法被标准对象分配的小块连续Region，形成一种特殊的“外部碎片”。

极客建议： 密切关注GC日志中的`Humongous allocation`。如果频繁出现，首先应该从应用层面反思：是否真的需要创建这么多大对象？常见的元凶包括：无限制的`byte[]`数组、大的`String`拼接、或是框架层不合理的缓存对象。如果无法避免，可以尝试调大Region Size（-XX:G1HeapRegionSize），使得更多对象可以作为普通对象分配，但这需要权衡对其他方面的影响。

性能优化与高可用设计

G1调优的核心思想是：**相信G1的自适应策略，只提供目标，而非干预过程。**

黄金法则：设定停顿时间目标，而非年轻代大小

从Parallel GC或CMS迁移过来的工程师，常犯的第一个错误就是手动设置年轻代大小（如 -Xmn, -XX:NewRatio）。这在G1中是强烈不推荐的。G1的精髓在于它可以根据你设定的停顿时间目标（-XX:MaxGCPauseMillis），动态调整年轻代的大小（在 -XX:G1NewSizePercent 到 -XX:G1MaxNewSizePercent 的范围内）来达成这个目标。如果停顿时间超标，G1会缩小年轻代，减少每次Young GC需要处理的对象数量；反之，则会扩大年轻代以提高吞吐量。手动设定年轻代大小会破坏这一核心自适应机制。

关键调优参数

  1. -XX:MaxGCPauseMillis=200

    这是最重要的参数，向G1传达你期望的最大STW停顿时间（单位毫秒）。G1会尽力达成，但这只是一个“软目标”，不是硬性保证。设置一个不切实际的低值（如20ms）在高负载下通常是无法达成的，反而可能导致G1过于频繁地执行小规模GC，降低了整体吞吐量。

  2. -XX:InitiatingHeapOccupancyPercent=45 (IHOP)

    触发并发标记周期的堆占用率阈值。默认值是45。如果你的应用对象分配速率很高，老年代增长很快，那么默认的45%可能太晚了，导致并发标记还没完成，老年代就满了，最终触发Full GC。在这种情况下，你需要调低此值（例如35-40）。反之，如果分配速率慢，可以适当调高此值，减少不必要的并发标记周期。最好的方法是通过监控老年代增长曲线来动态调整，或者使用G1的自适应IHOP功能（默认开启）。

  3. -XX:G1HeapRegionSize=n

    设定Region大小。JVM启动时会根据堆大小自动选择一个合适的值。通常不需要手动调整。但如果你有大量Humongous Object问题，可以尝试将其调大（例如从8MB到16MB），但请注意，这会使得RSet变得更加粗粒度，可能会增加RSet的内存占用和更新开销。

  4. -XX:ParallelGCThreads=n 和 -XX:ConcGCThreads=m

    分别控制STW阶段（Young GC, Remark等）和并发阶段的GC线程数。前者通常设置为CPU核心数，后者可以设置为ParallelGCThreads的1/4左右。在CPU资源紧张的容器化环境中，需要合理配置这些值，避免GC线程与业务线程争抢CPU。

实战：分析GC日志

开启详细GC日志是调优的第一步：-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=100m。关注以下关键信息：

  • Pause Young/Mixed： 观察停顿时间是否稳定在MaxGCPauseMillis目标附近。
  • to-space exhausted： 出现这个就意味着有Evacuation Failure，是需要立即处理的严重问题。
  • Concurrent Cycle Timings： 观察并发标记的各个阶段耗时，如果整体时间过长，说明在下一轮Mixed GC开始前，老年代可能已经积累了大量垃圾。
  • Humongous Allocation： 观察大对象分配的频率和大小。
  • Full GC： 任何一次Full GC都代表着G1的防线被攻破，需要深入分析其触发原因（例如 `to-space exhausted` 后的晋升失败，或元空间不足等）。

架构演进与落地路径

在生产环境中引入和优化G1，应遵循一个循序渐进的演进路径。

  1. 阶段一：基线建立与初步迁移

    对于现有使用CMS或Parallel GC的应用，迁移到G1的第一步是只设置 -XX:+UseG1GC 和 -XX:MaxGCPauseMillis，以及开启GC日志。在预发环境中进行充分的压力测试，收集基线性能数据。观察平均/P99停顿时间、吞吐量变化。通常，仅此一步就能对大多数大堆应用带来显著的停顿改善。

  2. 阶段二：响应式调优（处理明显问题）

    分析基线日志，寻找最突出的问题。如果频繁出现Evacuation Failure，首先考虑是否堆内存不足。如果停顿时间远超目标，检查是否存在大量的对象拷贝或RSet更新开销。如果Full GC被触发，根据日志找到原因，如果是IHOP太晚，就调低它。这个阶段的调优是“对症下药”。

  3. 阶段三：主动式优化（追求极致性能）

    当系统稳定运行在G1上后，可以进行更精细的优化。例如，微调IHOP以找到最佳平衡点；调整Mixed GC的积极性（通过-XX:G1MixedGCCountTarget等参数），在停顿和回收效率之间做权衡。对于极端延迟敏感的场景，可能需要结合应用代码的优化（例如使用对象池减少分配，避免大对象）来共同达成目标。

  4. 阶段四：展望未来（何时超越G1？）

    G1虽好，但并非银弹。它的STW阶段（尤其是Young GC和Remark）在超大堆（>100GB）和超低延迟（<10ms）要求下，仍然可能成为瓶颈。当你的业务演进到这个阶段，G1的调优已达极限时，就应该将目光投向更前沿的收集器，如ZGC和Shenandoah。它们通过更复杂的并发技术（如着色指针、转发指针），几乎将所有GC工作都并发化，实现了亚毫秒级的停顿。但这同样带来了更高的CPU开销和更复杂的实现。从G1到ZGC的演进，标志着系统对延迟的要求已经达到了另一个数量级。

总而言之，G1垃圾收集器通过Region化的堆布局和“Garbage-First”的回收策略，成功地在大内存时代解决了可预测停顿时间这一核心难题。掌握其底层原理，并结合科学的日志分析和系统性的调优方法，是每一位资深Java工程师必备的核心技能。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部