深入剖析G1垃圾收集器：从Region原理到STW调优实战

作者： /

本文旨在为有经验的工程师彻底厘清 Java G1 垃圾收集器（Garbage-First Garbage Collector）的核心设计哲学与内部工作机制。我们将绕开基础概念的冗长介绍，直击 G1 的命脉——基于 Region 的内存布局，剖析其如何通过可预测的停顿时间模型，在现代大内存（8GB+）多核服务器上，为低延迟、高吞吐的在线业务（如交易系统、风控引擎）提供有力支撑。本文将从底层原理、架构设计、实现细节、性能权衡和演进策略五个层面，为你构建一个完整且深入的 G1 知识体系。

现象与问题背景

在 G1 成为 Java 9 及以后版本的默认垃圾收集器之前，服务端应用主要依赖于 Parallel Scavenge/Parallel Old（吞吐量优先）和 Concurrent Mark Sweep (CMS)（低延迟优先）收集器。然而，随着业务复杂度的提升和内存需求的激增，这两种模式的弊端愈发明显：

  • Parallel GC 的“雪崩”式停顿： 它追求极致的吞吐量，在大部分时间里让应用全速运行。但一旦触发 Full GC，整个应用将陷入长时间的“Stop-The-World”(STW)，在几十 G 甚至上百 G 内存的服务器上，这个停顿时间可能从数百毫秒飙升至数秒甚至数分钟。对于任何要求 99.9% 可用性的在线服务，这都是一场灾难。想象一下，一个证券交易网关停顿 2 秒，可能意味着数万笔订单的延迟和巨大的潜在亏损。
  • CMS 的“并发失败”与内存碎片： CMS 通过并发标记和清理来减少停顿时间，但它并非完美。首先，“Concurrent Mode Failure”问题时常发生——如果在并发清理期间，业务线程产生的“浮动垃圾”过多，同时老年代空间不足以容纳从年轻代晋升的对象，CMS 会退化为一次长时间的 Full GC。其次，CMS 基于“标记-清除”算法，会产生大量内存碎片。当一个大对象（例如一个大的业务报文或风控模型）需要分配时，即使总的剩余空间足够，也可能因为没有连续的大块空间而提前触发 Full GC。

G1 的设计目标正是为了解决上述两难困境：在保持高吞吐量的同时，提供一个可预测的、短的停顿时间模型。它不再将堆划分为连续的年轻代和老年代，而是引入了一种全新的、更灵活的内存管理范式。

关键原理拆解

要理解 G1 的精髓，我们必须回归到计算机科学中关于内存管理和算法设计的基本原理。G1 的创新并非凭空而来，而是对经典理论的巧妙工程化应用。

1. 分而治之（Divide and Conquer）：非连续的堆内存布局

从操作系统的虚拟内存管理到数据库的分区表，分而治之是处理大规模数据问题的核心思想。传统的 GC 将整个堆视为几个巨大的连续块（Eden, S0, S1, Old），当 Old Gen 空间告急时，GC 必须扫描并处理整个 Old Gen，其工作量与 Old Gen 的大小强相关。G1 则将整个 Java 堆划分为大量大小相等的、不连续的独立区域（Region）。每个 Region 的大小通常是 1MB 到 32MB 之间的 2 的幂。这种设计从根本上改变了 GC 的工作模式：

  • 角色动态化： 每个 Region 在任意时刻都只扮演一种角色：Eden、Survivor、Old 或 Humongous（用于存储大对象）。这种角色不是固定的，一个 Region 在一次 GC 后可能会从 Eden 变为 Survivor，或者被回收变为空闲。这带来了极大的灵活性。
  • GC 粒度化： GC 的基本单位不再是整个“代”，而是若干个 Region 的集合。G1 可以选择性地对一部分 Region 进行回收，而不是每次都必须处理整个年轻代或老年代。

2. 贪心算法的应用：垃圾优先（Garbage-First）

G1 的名字来源正是其核心策略。在完成并发标记后，G1 已经知道了每个 Region 中存活对象的大小，从而可以计算出每个 Region 的“回收价值”——即垃圾最多、回收收益最高的区域。在执行 Mixed GC（混合回收）时，G1 会根据用户设定的目标停顿时间（-XX:MaxGCPauseMillis），贪心地选择一组回收价值最高的 Old Gen Region（Collection Set, CSet）进行回收，同时捎带上整个 Young Gen。这个策略的理论依据是：在有限的停顿时间内，优先清理垃圾最多的区域，以最小的停顿代价换取最大的空间释放。

3. 数据结构的重要性：Remembered Set (RSet)

分区域的设计带来一个巨大的挑战：如何处理跨 Region 的对象引用？当回收 Region A 时，我怎么知道 Region B 中是否有对象引用了 Region A 中的对象？如果需要扫描整个堆来确定，那分区就失去了意义。G1 的答案是 Remembered Set。每个 Region 都有一个与之关联的 RSet，它是一个哈希表或类似的数据结构，记录了“谁引用了我”。具体来说，Region A 的 RSet 记录了所有其他 Region 中，存在指向 Region A 内部对象的引用的“卡片（Card）”。一个 Card 大约对应堆上 512 字节的内存区域。这样，在回收 CSet 中的 Region 时，只需扫描这些 Region 的 RSet，就能找到所有外部的入引用，而无需遍历整个堆。这是空间换时间的典型范例。

系统架构总览

我们可以将 G1 的工作模式想象成一个精密的城市垃圾处理系统。整个城市（Java 堆）被划分为很多个街区（Region）。垃圾车（GC 线程）并非每次都清扫全城，而是有一个智能调度中心。

  • 内存布局： 整个堆由约 2048 个 Region 构成。这些 Region 在逻辑上扮演不同角色。新对象首先分配在 Eden Region。当 Eden 满了，触发 Young GC。

    • – Young GC： 这是一个纯粹的 STW 过程。所有 Eden Region 和上一轮的 Survivor Region 组成 CSet。存活的对象被拷贝到新的一组 Survivor Region 或直接晋升到 Old Region。这个过程本质上是并行的“复制-整理”算法，因此 Young GC 后的年轻代是无碎片的。
    – 并发标记周期： 当堆占用率达到某个阈值（-XX:InitiatingHeapOccupancyPercent，默认 45%）时，G1 会启动一个并发标记周期，为后续的 Mixed GC 做准备。这个周期包括：
    1. Initial Mark (STW): 初始标记。短暂 STW，标记所有从 GC Roots 直接可达的对象。通常借用 Young GC 的 STW 顺带完成。
    2. Concurrent Marking: 并发标记。GC 线程与应用线程并发执行，从 GC Roots 开始遍历整个堆的对象图。
    3. Remark (STW): 最终标记。短暂 STW，处理并发标记期间发生变化的对象引用（通过 SATB 算法实现）。
    4. Cleanup (STW/Concurrent): 清理。计算每个 Region 的存活对象和垃圾比例，并完全回收那些不包含任何存活对象的 Region。
    – Mixed GC： 在并发标记周期结束后，G1 就掌握了每个 Old Gen Region 的“垃圾价值”。接下来的数次 Young GC 将会“进化”为 Mixed GC。Mixed GC 不仅会回收所有 Young Gen Region，还会根据贪心策略，选择一部分回收价值高的 Old Gen Region 加入 CSet 一并回收。这也是一个 STW 的拷贝过程。通过参数 -XX:G1MixedGCLiveThresholdPercent 和 -XX:G1MixedGCCountTarget 控制哪些 Old Region 被选以及 Mixed GC 的执行次数。

    – Full GC： 当 G1 无法在正常回收中跟上内存分配速度时（例如，对象晋升时老年代空间不足，或并发模式失败），就会触发一次后备的、单线程的、长时间 STW 的 Full GC。这是我们需要极力避免的情况。

核心模块设计与实现

让我们像一位极客工程师一样，深入 G1 的内部，看看关键机制是如何用代码和数据结构支撑起来的。

Remembered Set (RSet) 与写屏障 (Write Barrier)

RSet 是 G1 实现 Region 独立回收的关键，而它的维护则依赖于 JVM 的写屏障技术。这并非硬件层面的内存屏障，而是一段由 JIT 编译器插入的、在对象字段赋值操作之后的额外代码。

当你执行一行看似简单的 Java 代码 x.f = y; 时，JIT 编译后的机器码大致如下：


// 伪代码，示意 G1 的 Post-Write Barrier
void G1BarrierSet::write_ref_field_post(oop obj, oop new_val) {
  // 如果新引用的值是 null，无需记录
  if (new_val == NULL) {
    return;
  }
  
  // 获取新值所在 Region
  G1HeapRegion* region_of_new_val = heap->heap_region_containing(new_val);
  
  // 获取引用字段所在 Region
  G1HeapRegion* region_of_obj = heap->heap_region_containing(obj);

  // 如果引用发生在同一个 Region 内，忽略
  if (region_of_obj == region_of_new_val) {
    return;
  }
  
  // 核心：在 new_val 所在 Region 的 RSet 中，记录一个来自 obj 的引用
  // 这需要将 obj 所在的 Card 加入到 region_of_new_val 的 RSet 中
  // RSet 的更新是异步的，通常是先将 "脏卡" (dirty card) 信息放入一个线程本地缓冲区
  CardTable* card_table = heap->card_table();
  int card_index = card_table->card_index_for(obj);
  
  if (!card_table->is_card_dirty(card_index)) {
    card_table->mark_card_dirty(card_index);
    // 将脏卡加入 Dirty Card Queue，由并发线程处理并更新到 RSet
    G1ThreadLocalData::enqueue_dirty_card(card_index);
  }
}

// 编译后的赋值操作
void compiled_assign(oop* field_addr, oop new_val) {
  *field_addr = new_val; // 原始的赋值操作
  G1BarrierSet::write_ref_field_post(containing_object_of(field_addr), new_val); // JIT 插入的写屏障
}

极客解读：
这套机制的开销不容忽视。每一次跨 Region 的引用赋值，都会触发这段写屏障代码。虽然有各种优化（如只在跨 Region 时处理，使用线程本地缓冲区减少竞争），但它仍然是 G1 相对于 Parallel GC 吞吐量较低的根源之一。这就是为可预测的停顿时间付出的“吞吐量税”。在设计系统时，如果对象的引用局部性非常差，频繁地在堆的各个角落建立引用关系，RSet 的维护成本就会显著上升。

并发标记与 SATB (Snapshot-At-The-Beginning)

在并发标记期间，应用线程还在不停地修改对象图。GC 如何保证不会漏掉任何存活对象？CMS 使用增量更新（Incremental Update），而 G1 使用的是 SATB。SATB 的核心思想是：在并发标记开始时，逻辑上对堆进行一个“快照”，所有在快照时刻存活的对象，无论在标记期间是否被修改，最终都会被认为是存活的。

这是通过另一个写屏障（Pre-Write Barrier）实现的。当一个对象引用即将被覆盖时，例如 x.f = y;，旧的引用值会被记录下来。


// 伪代码，示意 G1 的 Pre-Write Barrier for SATB
void G1SATBMarkQueueSet::write_ref_field_pre(oop* field_addr) {
  // 如果并发标记未激活，直接返回
  if (!G1ConcMark::is_active()) {
    return;
  }
  
  oop old_val = *field_addr;
  
  // 如果旧值是 null 或者已经处理过，忽略
  if (old_val == NULL || is_already_in_queue(old_val)) {
    return;
  }
  
  // 将旧的引用值放入线程本地的 SATB 标记队列
  G1ThreadLocalData::enqueue_satb_mark(old_val);
}

// 编译后的赋值操作
void compiled_assign(oop* field_addr, oop new_val) {
  // 在赋值前，记录旧值
  G1SATBMarkQueueSet::write_ref_field_pre(field_addr); 
  
  *field_addr = new_val; // 原始的赋值操作
  
  // G1 也有 Post-Write Barrier 用于 RSet
  G1BarrierSet::write_ref_field_post(containing_object_of(field_addr), new_val);
}

极客解读：
SATB 的好处是逻辑清晰，实现相对简单，能有效避免 CMS 中“浮动垃圾”导致并发失败的问题。但它的缺点是，可能会保留一些在标记期间实际上已经死亡的对象（因为它们在快照时是活的）。这些对象要等到下一次 GC 才能被回收。这对于那些对象生命周期变化极快的应用，可能会造成一定的内存浪费。但对于大部分服务端应用，这种保守的策略是稳定性和可预测性的坚实保障。

性能优化与高可用设计

理解了原理，我们才能进行有效的调优。G1 调优的核心思想是：帮助 G1 稳定地运行在 Young GC 和 Mixed GC 的循环中，坚决避免 Full GC。

  • 设定合理的停顿时间目标： -XX:MaxGCPauseMillis 是最重要的参数。不要盲目追求极低的停顿时间（如 20ms）。如果设置得太低，G1 为了达成目标，每次 Mixed GC 可能只选择极少数 Old Gen Region，导致垃圾回收速度跟不上产生速度，最终触发 Full GC。对于大部分 Web 应用，200ms 到 300ms 是一个比较现实和健康的起点。
  • 观察与调整 IHOP： -XX:InitiatingHeapOccupancyPercent（IHOP）决定了何时启动并发标记周期。默认值是 45%。如果你的应用有大量对象在 Old Gen 中生命周期很长（如缓存），可以适当调高此值，延迟并发标记的启动，减少 GC 开销。反之，如果对象晋升速度很快，或者存在大量浮动垃圾，应调低此值，让 G1 更早地开始标记，为 Mixed GC 准备。G1 在 JDK 9 以后引入了自适应 IHOP，通常无需手动调整。
  • 处理 Humongous Object： 大于 Region 大小一半的对象会被分配在 Humongous Region。Humongous Region 的回收比较棘手，通常只能在并发标记周期的 Cleanup 阶段或者 Full GC 时被回收。过多的 Humongous Allocation 会导致老年代碎片化和频繁的并发标记。优化的方向有两个：
    1. 应用层面：检查代码，避免创建不必要的超大对象。例如，一个超大的 `byte[]` 是否可以被 `ByteBuffer` 或者流式处理代替？
    2. JVM 层面：适当增加 Region 大小 -XX:G1HeapRegionSize（必须是 2 的幂，范围 1M-32M）。例如，如果频繁分配 2MB 的对象，而 Region 大小是 1MB，那么将 Region 调大到 4MB 会显著改善情况。
  • 日志分析是根本： 任何调优都必须基于数据。开启 GC 日志是最基本的操作：-Xlog:gc*:file=gc.log:time,level,tags:filecount=10,filesize=100m。关注日志中的 `to-space exhausted` 或 `Evacuation Failure`，这些是 Full GC 的直接诱因。同时观察 Young GC 和 Mixed GC 的耗时、CSet 的选择情况、并发标记各阶段的耗时，才能对症下药。

架构演进与落地路径

对于一个正在运行关键业务的系统，从 CMS/Parallel GC 迁移到 G1，需要一个稳健的演进策略，而不是一次性的“大爆炸”切换。

  1. 第一阶段：评估与基线建立 (1-2 周)
    • 目标： 不做任何变更，仅充分了解现有系统的 GC 状况。
    • 行动： 在生产环境（或负载完全一致的预发环境）中，为现有 JVM 添加详细的 GC 日志。收集至少一个完整业务周期的日志数据。
    • 产出： 使用 GCeasy、GCViewer 等工具分析日志，建立基线指标：平均/最大 STW 停顿时间、GC 频率、吞吐量占比、对象分配和晋升速率。
  2. 第二阶段：预发环境切换与初步调优 (2-4 周)
    • 目标： 在与生产环境一致的硬件和负载下，切换到 G1 并进行初步调优以达到或优于基线。
    • 行动：
      1. 切换到 G1：移除旧的 GC 参数，加上 -XX:+UseG1GC。
      2. 设定初始目标：仅设置 -Xms, -Xmx 和一个合理的 -XX:MaxGCPauseMillis（例如，基于 CMS 的平均 Young GC 停顿时间）。
      3. 进行压力测试和稳定性测试，收集 G1 的 GC 日志。
      4. 分析日志，对比基线。重点观察是否出现 Full GC，Mixed GC 是否能有效回收老年代。根据上一章节的调优策略，微调 IHOP 或处理 Humongous Object 问题。
    • 产出： 一套在预发环境验证过的、稳定的 G1 启动参数。一份 G1 在同等负载下的性能表现报告。
  3. 第三阶段：灰度发布与生产监控 (持续)
    • 目标： 平滑地将 G1 推向生产环境，并建立完善的监控告警。
    • 行动：
      1. 选择部分流量较小、非核心的实例进行灰度发布。
      2. 密切监控这些实例的 GC 指标（停顿时间、频率、老年代使用率）和业务指标（响应时间、错误率）。
      3. 确认无误后，逐步扩大灰度范围，直至全量覆盖。
      4. 将 G1 的关键指标（如 Full GC 次数、P99 停顿时间）纳入核心监控大盘和告警系统。任何 Full GC 的发生都应触发高优告警。
    • 产出： 全量运行 G1 的生产集群，以及配套的、成熟的监控与应急预案。

总结而言，G1 垃圾收集器是现代 JVM 在大内存、多核时代下的标准答案。它通过 Region 化的内存布局和“垃圾优先”的回收策略，成功地将不可控的 Full GC 停顿转变为一系列可预测的、短暂的 Mixed GC 停顿。掌握 G1 的核心原理，不仅仅是为了调优几个 JVM 参数，更是为了深刻理解在复杂工程约束下，如何通过精巧的算法和数据结构设计，在性能、延迟和资源开销之间找到那个微妙而关键的平衡点。

延伸阅读与相关资源

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