目录
- [1. 引言：Go 1.25 带来的 GC 新变量](#1. 引言：Go 1.25 带来的 GC 新变量 "#1-%E5%BC%95%E8%A8%80go-125-%E5%B8%A6%E6%9D%A5%E7%9A%84-gc-%E6%96%B0%E5%8F%98%E9%87%8F")
- [2. 核心思想：以页为单位工作，而非以对象为单位](#2. 核心思想：以页为单位工作，而非以对象为单位 "#2-%E6%A0%B8%E5%BF%83%E6%80%9D%E6%83%B3%E4%BB%A5%E9%A1%B5%E4%B8%BA%E5%8D%95%E4%BD%8D%E5%B7%A5%E4%BD%9C%E8%80%8C%E9%9D%9E%E4%BB%A5%E5%AF%B9%E8%B1%A1%E4%B8%BA%E5%8D%95%E4%BD%8D")
- [3. 与传统 mark-sweep 的对比](#3. 与传统 mark-sweep 的对比 "#3-%E4%B8%8E%E4%BC%A0%E7%BB%9F-mark-sweep-%E7%9A%84%E5%AF%B9%E6%AF%94")
- [4. 页级元数据：每个对象两个 bit](#4. 页级元数据：每个对象两个 bit "#4-%E9%A1%B5%E7%BA%A7%E5%85%83%E6%95%B0%E6%8D%AE%E6%AF%8F%E4%B8%AA%E5%AF%B9%E8%B1%A1%E4%B8%A4%E4%B8%AA-bit")
- [5. 向量硬件加速：AVX-512 与位操作](#5. 向量硬件加速：AVX-512 与位操作 "#5-%E5%90%91%E9%87%8F%E7%A1%AC%E4%BB%B6%E5%8A%A0%E9%80%9Favx-512-%E4%B8%8E%E4%BD%8D%E6%93%8D%E4%BD%9C")
- [6. 性能收益：10% 到 40%](#6. 性能收益：10% 到 40% "#6-%E6%80%A7%E8%83%BD%E6%94%B6%E7%9B%8A10-%E5%88%B0-40")
- [7. 实验性开启方式](#7. 实验性开启方式 "#7-%E5%AE%9E%E9%AA%8C%E6%80%A7%E5%BC%80%E5%90%AF%E6%96%B9%E5%BC%8F")
- [8. 易错点与常见误解](#8. 易错点与常见误解 "#8-%E6%98%93%E9%94%99%E7%82%B9%E4%B8%8E%E5%B8%B8%E8%A7%81%E8%AF%AF%E8%A7%A3")
- [8.1 它不是「更快的 GC 算法」那么简单](#8.1 它不是「更快的 GC 算法」那么简单 "#81-%E5%AE%83%E4%B8%8D%E6%98%AF%E6%9B%B4%E5%BF%AB%E7%9A%84-gc-%E7%AE%97%E6%B3%95%E9%82%A3%E4%B9%88%E7%AE%80%E5%8D%95")
- [8.2 小堆场景收益有限](#8.2 小堆场景收益有限 "#82-%E5%B0%8F%E5%A0%86%E5%9C%BA%E6%99%AF%E6%94%B6%E7%9B%8A%E6%9C%89%E9%99%90")
- [8.3 大堆且对象密集的负载收益更明显](#8.3 大堆且对象密集的负载收益更明显 "#83-%E5%A4%A7%E5%A0%86%E4%B8%94%E5%AF%B9%E8%B1%A1%E5%AF%86%E9%9B%86%E7%9A%84%E8%B4%9F%E8%BD%BD%E6%94%B6%E7%9B%8A%E6%9B%B4%E6%98%8E%E6%98%BE")
- [8.4 实验性特性不建议生产默认开启](#8.4 实验性特性不建议生产默认开启 "#84-%E5%AE%9E%E9%AA%8C%E6%80%A7%E7%89%B9%E6%80%A7%E4%B8%8D%E5%BB%BA%E8%AE%AE%E7%94%9F%E4%BA%A7%E9%BB%98%E8%AE%A4%E5%BC%80%E5%90%AF")
- [8.5 默认开启的时间点](#8.5 默认开启的时间点 "#85-%E9%BB%98%E8%AE%A4%E5%BC%80%E5%90%AF%E7%9A%84%E6%97%B6%E9%97%B4%E7%82%B9")
- [9. 学习目标与总结](#9. 学习目标与总结 "#9-%E5%AD%A6%E4%B9%A0%E7%9B%AE%E6%A0%87%E4%B8%8E%E6%80%BB%E7%BB%93")
1. 引言：Go 1.25 带来的 GC 新变量
Go 语言一直以「低延迟 GC」作为核心竞争力之一，从早期的并发标记清除，到 Go 1.5 的并发 GC 重构，再到 Go 1.19 引入的软内存上限，每一次 GC 演进都在试图回答同一个问题：如何在保证吞吐的同时，把停顿压到最低？
Go 1.25 引入的 Green Tea GC 给出了一个相当不同的答案。它并不是简单地「把标记算法换得更快」，而是从底层改变了 GC 的内存访问模式------把工作单位从「对象」换成「页」。
本文将从设计思想、实现机制、硬件加速、性能收益和实验性开启方式几个维度，系统梳理 Green Tea GC 的核心知识点，并给出可复现的验证命令，帮助你判断是否值得在自己的项目中试用。
2. 核心思想：以页为单位工作，而非以对象为单位
Green Tea GC 最核心的一句话可以概括为：
以页为单位工作，而非以对象为单位。
传统标记清除（mark-sweep）GC 在标记阶段会沿着对象图游走：从根对象出发，读取一个对象的指针字段，跳转到它指向的下一个对象，再读取下一个对象的指针......这个过程本质上是指针追逐（pointer chasing），访问地址高度随机。
Green Tea 则把扫描的粒度提升到「页」这一层：GC 不再逐个对象地跳转，而是按页扫描，把一页内所有对象的元数据集中处理。这样做的直接好处是：
- 减少随机内存访问：同一页内的数据在物理内存上相邻，扫描时缓存命中率显著提升；
- 提升缓存局部性：一次加载可以服务多个对象的标记判断；
- 便于向量化：页内元数据是规整的位图，天然适合 SIMD 指令批量处理。
换句话说，Green Tea 的收益主要来自内存访问模式的改变，而不是算法复杂度层面的突破。理解这一点，是理解它性能表现的前提。
下面用一张图对比两种扫描方式在内存访问上的差异：
左侧是典型的指针追逐，箭头在堆上四处跳跃；右侧则把工作单位收敛到页，扫描顺序与内存布局基本一致。
3. 与传统 mark-sweep 的对比
为了更直观地看清差异，我们把两种方式放在一起对比：
| 维度 | 传统 mark-sweep | Green Tea GC |
|---|---|---|
| 工作单位 | 对象 | 页（page） |
| 遍历方式 | 沿对象图指针追逐 | 按页顺序扫描 |
| 内存访问 | 随机跳转频繁 | 局部性好、顺序访问 |
| 元数据组织 | 分散在对象头 | 按页聚合为位图 |
| 工作列表 | 对象队列 | 页队列 |
| 硬件利用 | 难以向量化 | 适合 SIMD 批量处理 |
传统方式的问题在于：对象在堆上的分布是碎片化的，指针追逐会导致大量 cache miss。而 Green Tea 把「一页」当作一个整体来处理，扫描循环内部是高度规整的位运算，CPU 的预取器和缓存行都能被充分利用。
可以用下面的流程图概括 Green Tea 的扫描流程：
4. 页级元数据：每个对象两个 bit
Green Tea 在元数据设计上非常克制：每个对象只维护两个 bit。
- seen 位：表示该对象是否已被发现（被某个指针引用到）；
- scanned 位：表示该对象的字段是否已经被扫描过。
这两个 bit 按页聚合存储，形成页级的位图（bitmap）。由于一页的大小是固定的（Go 的页通常为 8KB），一页内能容纳的对象数量有上限，因此整页的元数据可以放进极少的机器字中。
工作列表跟踪的对象也随之改变：队列里放的是「页」，而不是「对象」。这带来两个好处：
- 队列元素数量大幅减少，降低了 GC 自身的调度开销；
- 处理一页时可以一次性完成该页内所有对象的标记判断，摊薄了单对象的成本。
这种「位图 + 页队列」的组合，是 Green Tea 能够高效利用硬件的关键前提。
页级元数据的组织方式可以直观地表示为：
可以看到，两个位图与页一一对应，队列里流动的是页而不是对象，这正是「位图 + 页队列」能够摊薄单对象成本的原因。
5. 向量硬件加速：AVX-512 与位操作
页级元数据的规整性，让 Green Tea 可以充分利用现代 CPU 的向量指令。
在支持 AVX-512 的平台上，一个 512 位的宽寄存器可以一次处理 64 个 bit。由于整页的元数据规模很小，一页的元数据可以放入两个寄存器，扫描循环因此可以被大幅加速：
- 用宽寄存器一次性加载整页的 seen/scanned 位图；
- 用位运算指令批量完成「哪些对象已标记」「哪些对象待扫描」的判断；
- 用掩码（mask）操作直接筛选出需要处理的对象，避免逐位循环。
这意味着原本需要循环遍历每个对象的扫描逻辑，被压缩成了几条向量指令。对于对象密集的堆，这种加速效果尤为明显。
需要强调的是，向量加速是收益的放大器，而不是收益的来源。真正的收益基础仍然是第 2 节所说的内存访问模式改变；AVX-512 只是让这个模式跑得更快。
从数据流角度看，向量化扫描大致经历以下几个阶段：
原本需要逐对象循环的判断，被压缩成寄存器内的几条指令，这也是对象密集堆收益更明显的原因。
6. 性能收益：10% 到 40%
根据官方公布的数据，Green Tea GC 的性能表现大致如下：
- 多数工作负载 ：GC 时间减少约 10%；
- 部分工作负载 ：GC 时间减少高达 40%。
这里的「部分工作负载」通常具备以下特征：
- 堆规模较大（数百 MB 以上）；
- 对象数量多且分布密集；
- 指针关系复杂，传统方式下指针追逐开销显著。
反过来说，如果你的程序堆很小、对象很少，那么 Green Tea 带来的收益会非常有限------因为此时 GC 时间本身占比就不高，内存访问模式的优化空间也不大。
是否值得试用，可以按下面的思路快速判断：
这张图也呼应了第 8 节的结论：Green Tea 的收益取决于堆的形态，而不是一个放之四海皆准的百分比。
7. 实验性开启方式
Green Tea GC 在 Go 1.25 中属于实验性特性 ，默认并未开启，需要通过 GOEXPERIMENT 环境变量显式启用：
bash
# 开启 Green Tea GC 实验
GOEXPERIMENT=greenteagc go run main.go如果想对比开启前后的 GC 行为，可以结合 gctrace 观察：
bash
# 对比 GC trace
GODEBUG=gctrace=1 GOEXPERIMENT=greenteagc go run main.go在输出中重点关注形如 gc N @Ts %: ... 的行，观察其中的停顿时间 和 CPU 占比变化：
text
gc 1 @0.012s 0%: 0.015+0.32+0.004 ms clock, 0.12+0.28/0.15/0.004+0.032 ms cpu, 4->4->2 MB, 5 MB goal, 8 P建议的对比方法是：同一份程序、同一份输入，分别在开启和关闭 greenteagc 的情况下各跑多次，取中位数比较，避免单次抖动带来的误判。
8. 易错点与常见误解
在实际讨论中，关于 Green Tea 有几个高频误解，值得单独澄清。
8.1 它不是「更快的 GC 算法」那么简单
Green Tea 改变的是内存访问模式，而不是标记算法的复杂度。它的收益高度依赖堆的形态：对象越密集、指针关系越复杂，收益越明显；反之则可能几乎无感。
8.2 小堆场景收益有限
对于小堆、短生命周期对象为主的程序，GC 时间占比本来就低，Green Tea 的优化空间有限。不要指望在小服务上看到 40% 的提升。
8.3 大堆且对象密集的负载收益更明显
数百 MB 以上的堆、大量存活对象、复杂指针图，才是 Green Tea 的主场。评估时应当以真实生产负载的堆形态为准。
8.4 实验性特性不建议生产默认开启
greenteagc 在 Go 1.25 中仍是实验性开关，不建议在生产环境默认开启。如果确实想试用，应当：
- 在预发/灰度环境充分测试；
- 对比 GC trace、P99 延迟、CPU 使用率等关键指标；
- 关注是否有行为差异或兼容性问题。
8.5 默认开启的时间点
官方计划在 Go 1.26 中将 Green Tea GC 设为默认。这意味着 Go 1.25 是观察和验证的窗口期，提前在测试环境跑通，有助于平滑过渡。
9. 学习目标与总结
回顾全文，Green Tea GC 的核心知识点可以浓缩为以下几点：
- 核心思想：以页为单位工作，而非以对象为单位；
- 与传统 mark-sweep 的区别：传统方式在对象图上游走、跳转频繁，Green Tea 按页扫描，减少随机访问、提升缓存局部性；
- 页级元数据：每个对象两个 bit（seen/scanned），按页聚合，工作列表跟踪的是页而非对象；
- 向量硬件加速：利用 AVX-512 的宽寄存器和位操作指令，整页元数据可放入两个寄存器，扫描循环大幅加速；
- 性能收益：多数工作负载 GC 时间减少约 10%，部分工作负载减少高达 40%，计划在 Go 1.26 设为默认；
- 实验性开启方式 ：
GOEXPERIMENT=greenteagc。
学习目标应当是：理解 Green Tea 的设计取舍，能够评估是否在自己的项目中试用，并会解读 GC trace 的变化。
它不是一颗「万能提速药」，而是一次针对内存访问模式的系统性优化。看清它的适用边界，比记住那几个百分比数字更重要。