Go 新垃圾回收器 Green Tea 即将登场

随着 CPU 核心数量的激增和内存访问速度日益成为瓶颈，现代计算系统对内存局部性（Spatial & Temporal Locality）和拓扑感知（Topology-awareness）提出了更高的要求。然而，传统的垃圾收集（GC）算法，包括 Go 当前使用的并行三色标记清除法，往往与这些趋势背道而驰。近期，Go 团队技术负责人 Austin Clements 公布了一项名为 "Green Tea" (绿茶) 的实验性垃圾收集器设计（Issue #73581），旨在通过一种内存感知 (memory-aware) 的新方法，显著改善 GC 过程中的内存访问模式，降低 CPU 开销，尤其是在多核和 NUMA 架构下。该特性计划作为 Go 1.25 的一个可选实验加入，开发者将有机会提前体验。

在这篇文章中，我就来简要介绍一下这个新GC的设计、原型实现和当前状态。

当前 GC 的挑战：内存墙与低效扫描

Go 当前的 GC 算法本质上是一个图遍历过程，堆对象是节点，指针是边。这种“图泛洪”式的扫描在并发标记时，会频繁地在内存地址空间中跳跃，导致：

• 空间局部性差: 处理逻辑上相邻的对象时，物理内存访问可能跨越很大范围。

• 时间局部性差: 对同一内存区域的重复访问分散在整个 GC 周期中，未能有效利用缓存。

• 缺乏拓扑感知: 无法根据 CPU 核心与内存的物理距离进行优化。

其结果是，GC 的核心环节——扫描循环 (scan loop)——平均消耗了 GC 总时间的 85%，而其中超过 35%的 CPU 周期仅仅是等待内存访问 (stalled on memory accesses)，这还不包括连锁反应。随着硬件向多核、深层缓存和非统一内存架构（NUMA）发展，这个问题预计将更加严峻。

Green Tea 设计：从对象扫描到 Span 扫描

• Green Tea GC 的核心思想是改变扫描的基本单位。它不再直接处理和排队单个对象，而是扫描更大、连续的内存块，称为 "Spans"。

• Span 作为工作单元: GC 的共享工作队列现在追踪的是 Spans，而不是单个待扫描对象。

• Span 内部追踪: 一个 Span 内部需要扫描的对象信息（标记位）被存储在该 Span 自己的元数据中。

• 核心假设: 当一个 Span 在队列中等待时，程序可能会继续标记该 Span 内的其他对象。这样，当这个 Span 最终被取出处理时，它内部可能积累了多个待扫描对象，使得一次 Span 扫描能够处理更多邻近的对象，从而提高内存访问的局部性，并摊销单次扫描的固定开销。

Green Tea 的原型实现 (CL 658036[1]) 已经可供试用，其关键特性包括：

1. 聚焦小对象: 原型目前主要针对小对象 Spans（包含 <= 512 字节对象的 8KiB 对齐内存块）。这是因为小对象的单次扫描时间短，传统 GC 的固定开销占比更高，优化潜力更大。大对象仍使用旧算法。

2. 高效元数据访问: 利用 Span (8KiB 对齐) 的特性，通过简单的地址运算即可定位 Span 内对象的元数据（灰/黑标记位），避免了耗时的间接寻址和依赖加载。使用一个全局位图快速判断指针目标是否属于小对象 Span。

3. 优化的工作分发: 采用类似 Goroutine 调度器的分布式工作窃取队列 (work-stealing runqueues) 来管理 Span 任务。这减少了对全局列表的争用，提高了多核扩展性。实验表明，FIFO 策略能让 Span 在被处理时积累最高的平均对象密度。

4. 单对象扫描优化: 为了处理 Span 被取出时内部只有一个对象待扫描的低效情况，引入了优化：

5. 记录使 Span 入队的那个对象作为“代表 (representative)”。

6. 增加一个“命中 (hit)”标志，表示 Span 在队列中时是否有其他对象被标记。

7. 如果出队时“命中”标志未设置，则直接扫描“代表”对象，避免处理整个 Span 的开销。

原型评估：显著改进与复杂场景

团队在多种环境（不同核心数、amd64/arm64）下对 Green Tea 原型进行了评估：

• GC 密集型微基准: 在 x/benchmarks/garbage 和 binary-trees 等基准测试中，观察到 GC CPU 成本降低了 10% 到 50%，且改进幅度随核心数增加而提高，L1/L2 缓存未命中次数减半。这表明新设计具有更好的可伸缩性。

• 更广泛的基准套件 (bent & sweet): 结果更为复杂。

0. 许多基准测试影响不大，或性能变化由 GC 无关因素（如代码对齐）导致。

1. 部分出现回归：原因可能是 GC 时间缩短导致浮动垃圾减少（影响某些依赖内存压力的基准），或暴露了应用/运行时中其他的伸缩性瓶颈。

2. Go 编译器基准: 出现微小且不一致的回归（约 0.5%），可能与 PGO 配置有关，总体不敏感。

3. tile38 (高扇出树): 吞吐量、延迟和内存使用均有显著改善，GC 开销降低 35%。Green Tea 在这种能快速产生大量工作和高密度的场景下表现优异。

4. bleve-index (低扇出、频繁变异的二叉树): 性能基本持平，但揭示了 Green Tea 的局限性。当应用自身内存局部性差（如频繁树旋转导致节点分散）时，Green Tea 难以凭空创造局部性。单对象扫描优化对此类场景至关重要。在高核数环境下，由于伸缩性改善，仍有显著提升。

关键结论: Green Tea 在应用本身具有良好内存局部性的情况下表现最佳，并且其设计在多核环境下的伸缩性优于当前 GC。

未来工作：SIMD 加速与更高密度

Green Tea 的 Span 扫描模式为未来的优化打开了大门：

1. SIMD 加速扫描内核: 通过为不同大小类生成专门的 SIMD（单指令多数据流）扫描代码，利用位操作、置换指令等批量处理指针的加载、掩码、重排和入队。原型已证明 AVX512 内核能在已有改进的基准上再降低 15-20% GC 开销，但目前仅适用于部分对象且需要足够高的扫描密度。

2. Concentrator Network: Austin Clements 最初的设计包含一个更复杂的“集中器网络”排序结构，旨在实现 SIMD 所需的更高指针密度，并为元数据操作（如设置灰色位）带来局部性。虽然因实现复杂性暂未优先实施，但作为一种更通用、可调优的方案，仍是未来的探索方向。

   立即体验 Green Tea GC

   Go 团队鼓励开发者在自己的真实应用上尝试 Green Tea GC（计划在 Go 1.25 中作为 GOEXPERIMENT 提供）：

3. 安装 gotip:go install

   gotip download

4. 使用 gotip 编译并运行:gotip build -gcflags=all=-N -ldflags=all=-w # 示例：禁用优化和 DWARF以便分析

   GOEXPERIMENT=greenteagc GODEBUG=gctrace=2 ./your_program(注意：请根据实际情况调整编译参数)

   反馈渠道: 团队希望收集关于实际应用场景的反馈，特别是：

• 运行平台和 CPU 型号（或云实例类型）。

• GOMAXPROCS 设置。

• 开启/关闭 Green Tea (GOEXPERIMENT=nogreenteagc) 时的 GODEBUG=gctrace=2 输出。

• 开启/关闭 Green Tea 时的 CPU Profile。

• 开启/关闭 Green Tea 时的执行 Trace（捕获几个 GC 周期）。

  可以在 GitHub Issue #73581[2] 下评论，或直接邮件联系 mknyszek(at)golang.org。

总结与展望

Green Tea GC 是 Go 团队应对现代硬件内存瓶颈挑战的一次重要探索。通过转向内存感知的 Span 扫描设计，它在早期测试中展现了降低 GC 开销和提高多核伸缩性的巨大潜力。虽然仍在实验阶段，且在某些场景下表现复杂，但其方向代表了 Go 运行时为了持续榨取硬件性能而进行的重要演进。社区的积极试用和反馈将对 Green Tea 的最终形态和未来 Go 版本的性能产生关键影响。

来源：知乎 Tony Bai