Go 1.26 把 Green Tea 设成了默认 GC。发布说明里只有干巴巴的一句话：「在大量使用 GC 的真实程序中，垃圾回收开销降低 10%~40%」。

大多数人看到这句就划过去了——反正是白嫖，升级就完事。

但如果你把这句话拆开看，会发现它其实在讲一件更狠的事：Go 团队花了八年时间，把标记算法的基本工作单元从「对象」换成了「页」。这不是调参，不是加个 fast path，是把 mark 阶段的数据结构、元数据布局、工作队列语义全部推倒重来，顺便让 GC 史上第一次真正吃到了 SIMD。

这篇文章不做 release notes 搬运。我们从「为什么老 GC 会慢」这个微架构问题出发，一路拆到 Green Tea 的页扫描主循环、seen/scanned 双 bit 元数据、AVX-512 向量内核里那条 VGF2P8AFFINEQB 指令，然后落到最实际的地方：你的代码要怎么写，才能把这 10%~40% 真正吃到嘴里——以及什么情况下 Green Tea 反而会给你负优化。

一句话结论（赶时间的看这段）

• 原理：老 GC 是「发现一个对象 → 立刻追它的指针 → 跳到另一处内存」，内存访问随机；Green Tea 是「先把一整页里所有待扫的对象攒起来 → 按内存顺序一次扫完」，内存访问连续。
• 收益来源：不是算法复杂度变了（还是 O(存活对象)），是缓存命中率变了。GC 标记阶段有 35% 以上的时间在等内存，这部分被压下去了。
• 额外红利：页内对象等大 → 元数据格式规整 → 可以用 AVX-512 一次处理整页元数据，amd64 上再降约 10%。
• 谁受益最大：小对象多、对象图密集、堆大的服务（网关、RPC 框架、缓存层、编译器/解析器）。
• 谁可能吃亏：对象图极稀疏、每页只有一两个存活对象的负载。
• 你要做的事：升级 + 用 runtime/metrics 做 A/B，然后按第 7 节的七条规律改造热点数据结构——改数据布局的收益，比升级 GC 本身大一个数量级。

一、背景：GC 不是变慢了，是硬件把它甩下了

1.1 三个把人打醒的数字

Go 运行时团队对 GC 开销做过分解，得到三个数字，我认为是理解这次改动的全部前提：

把这三个数乘一乘：一个 GC 占 20% CPU 的服务，其中 20% × 90% × 35% ≈ 6.3% 的整机 CPU，是 CPU 核心什么都没干、纯粹在等 DRAM 把数据搬进来。

sweep 阶段只占 10%，早就不是矛盾主要方面了。过去十年 Go GC 的工作重心（并发标记、混合写屏障、抢占式 STW 缩短）都在解决延迟问题——STW 已经压到亚毫秒。但吞吐这块，一直卡在内存墙上。

1.2 硬件的四条趋势，条条都在打老 GC 的脸

这事儿还在恶化，因为过去十年硬件的演进方向，和图泛洪（graph flooding）式标记的访问模式正好相反：

① 核多了，但单核内存带宽在降。 一颗 128 核的服务器 CPU，总带宽是涨了，但摊到每核比十年前的 8 核机器还少。随机访问在带宽紧张时的代价被放大。

② NUMA 越来越明显。 跨 NUMA node 访问内存的延迟可能是本地的 1.5~2 倍。图泛洪完全不感知拓扑——它顺着指针跑，指针指哪它去哪。

③ 缓存层级差距拉大。 L1 命中约 4 cycle，LLC 约 40 cycle，DRAM 200~300+ cycle。这是接近 100 倍的差距，而且这个比例这些年只增不减。

④ 向量单元越来越宽。 AVX-512 给了 512 bit 寄存器，AMX 甚至给了矩阵单元。但老 GC 一次只处理一个大小不定的对象，元数据格式各不相同，一条向量指令都用不上。

Go 团队内部有工程师把这种情况直接称为「微架构灾难」（microarchitectural disaster）。这个词不夸张。

二、核心概念：为什么 pointer chasing 是 CPU 的天敌

2.1 先把老 mark-sweep 摆出来

Go 用的是经典的并发三色标记-清扫。标记阶段本质是一次图遍历：

worklist = 所有根（全局变量 + 各 goroutine 栈上的指针）
while worklist 非空:
    obj = worklist.pop()          // 拿一个对象
    for ptr in obj 的指针字段:     // 需要读对象内容 + 读它的指针位图
        if 目标未标记:
            标记目标
            worklist.push(目标)    // 目标可能在几 MB 之外

注意 worklist 里放的是对象，pop 出来的对象在内存里的位置是任意的。

2.2 依赖链把乱序 CPU 变回了单发射机器

现代 CPU 的性能来自两件事：乱序执行（找出互不依赖的指令并行做）和硬件预取（猜到你下一步要读哪，提前搬进缓存）。

指针追逐把这两件事同时废掉了：

• 地址依赖：你必须先拿到 obj 的内容，才知道下一个地址是什么。这是一条严格串行的依赖链，乱序窗口再大也没用——所有后续访存都在等这一次 load 返回。
• 预取失效：硬件预取器识别的是 stride pattern（等步长）。指针跳转没有任何 stride 可言，预取器只能干瞪眼。
• 工作量太小：扫完一个对象通常只有几个到十几个字。也就是说「等 300 cycle → 干 20 cycle → 再等 300 cycle」，占空比惨不忍睹。

2.3 用代码感受一下这个差距

不用信我，自己跑一下。构造两条一模一样长度、一模一样节点数的链表，唯一区别是节点在内存里的顺序：

// chase_test.go
package chase

import (
	"math/rand"
	"testing"
)

const N = 1 << 22 // 4M 个节点

type node struct {
	next *node
	_    [56]byte // 撑满 64 字节，一个节点独占一条 cache line
}

// 顺序布局：节点 i 的 next 指向节点 i+1，内存地址单调递增
func buildSeq() *node {
	arr := make([]node, N)
	for i := 0; i < N-1; i++ {
		arr[i].next = &arr[i+1]
	}
	return &arr[0]
}

// 随机布局：同一块内存，但链接顺序被完全打乱
func buildShuffled() *node {
	arr := make([]node, N)
	perm := rand.Perm(N)
	for i := 0; i < N-1; i++ {
		arr[perm[i]].next = &arr[perm[i+1]]
	}
	return &arr[perm[0]]
}

func walk(h *node) int {
	n := 0
	for p := h; p != nil; p = p.next {
		n++
	}
	return n
}

func BenchmarkSeq(b *testing.B) {
	h := buildSeq()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		if walk(h) != N {
			b.Fatal("bad")
		}
	}
}

func BenchmarkShuffled(b *testing.B) {
	h := buildShuffled()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		if walk(h) != N {
			b.Fatal("bad")
		}
	}
}

跑：

go test -run '^$' -bench . -benchtime 3x -count 5

两个 benchmark 访问的字节数完全相同、指令数完全相同，唯一差别是访问顺序。在我见过的大多数 x86 服务器上，Shuffled 会比 Seq 慢好几倍——多出来的时间全是在等 DRAM。

老 GC 的 mark 阶段，就是 BenchmarkShuffled。Green Tea 想把它变成 BenchmarkSeq。

三、Green Tea 的核心思想：工作单元从「对象」换成「页」

Go 团队给出的解法可以浓缩成一句话：

以页（page）为单位追踪和扫描，而不是以对象为单位。

听起来平平无奇。魔鬼全在细节里。

3.1 前置条件：Go 的 span 布局天生适合这么干

Go 的堆内存管理有一个关键性质，是 Green Tea 全部优化的地基：

• 运行时把堆切成 8 KiB 对齐的页（pageSize = 8192）；
• 小对象按 size class 分配，同一个 mspan 只放同一 size class 的对象；
• 因此：同一页内的所有对象大小完全相同、地址等间距排列。

这句话值得念三遍。它意味着页内的对象是一个规整数组，而不是一堆参差不齐的东西。这个性质在老 GC 里几乎没被利用，在 Green Tea 里是整个设计的支点。

举例：一个存放 32 字节对象的页，里面整整齐齐躺着 8192/32 = 256 个对象槽位，第 k 个对象的地址就是 spanBase + k*32。不需要查表，一次乘法就算出来。

3.2 元数据从 1 bit 变成 2 bit：seen 和 scanned

老 GC 每个对象一个 mark bit：标了就是活的。

Green Tea 每个对象两个 bit：

为什么要拆开？因为老 GC 里「发现」和「扫描」是紧挨着发生的：标记完立刻 push 进 worklist，很快就被 pop 出来扫掉。Green Tea 要做的恰恰是把这两件事在时间上分开——先攒着，攒够了再一次性扫。

seen && !scanned 的对象集合，就是「这一页当前欠的活」。

3.3 扫描主循环

伪代码（对应真实实现里的 span queue + scan kernel）：

workqueue = FIFO 队列，元素是页（span）

// 初始化：处理根
for each root pointer p:
    span = spanOf(p)
    set seen[objIndex(p)]
    if span 不在 workqueue: workqueue.enqueue(span)

// 主循环
while workqueue 非空:
    span = workqueue.dequeue()        // FIFO，不是 LIFO

    // 一次性算出这一页欠的活：seen 但还没 scanned
    todo = seen[span] &^ scanned[span]     // 位运算，一次搞定整页
    scanned[span] |= todo

    // 关键：按地址顺序，连续扫这些对象
    for k in bitsSetInOrder(todo):
        objAddr = span.base + k*span.elemsize
        for ptr in 该对象的指针字段:       // 指针位图对整页是同一份
            tgt = *ptr
            tspan = spanOf(tgt)
            ti = objIndex(tgt)
            if !seen[tspan][ti]:
                set seen[tspan][ti]
                if tspan 不在 workqueue:
                    workqueue.enqueue(tspan)

对比老算法，三个变化：

1. 队列里放页，不放对象。页的数量比对象少一到两个数量级，队列压力天然下降。
2. todo 是一次位运算算出来的，不是一个一个判断。
3. 内层循环按地址顺序走：span.base + 0*sz、+1*sz、+2*sz……这是标准的 stride 访问，硬件预取器立刻就能识别并提前把后面的 cache line 拉进来。

3.4 为什么必须是 FIFO 而不是 LIFO

这是最容易被忽略、但最关键的设计决策之一。

老 GC 的 worklist 通常倾向 LIFO（栈），因为 DFS 局部性好、栈深度可控。Green Tea 反过来用 FIFO（队列），原因是：

页在队列里等待的时间越长，攒到的 seen 对象越多，一次出队能扫的对象就越多。

如果用 LIFO，页刚入队就被弹出来，往往只有 1 个 seen 对象——那和老 GC 没区别，还白白多付了两倍元数据的成本。FIFO 制造了一个天然的批处理窗口：在页排队的这段时间里，别的 worker 可能又往这一页里塞了几个 seen bit。

这是典型的用延迟换吞吐。因为标记是并发的（业务代码还在跑），多等一会儿不影响 STW 时间，纯赚。

堆越大，这个效果越好——堆大意味着队列长，页等待时间长，攒得更多。这就解释了为什么官方数据里「重度使用 GC 的真实程序」收益最明显，而 hello world 级别的程序看不出差别。

3.5 单对象页的快速路径

反过来想：如果一页里就攒到 1 个对象，Green Tea 的所有额外开销（两倍元数据、入队出队、位运算）就全是白费。

Go 团队对这种情况做了特殊处理：单对象页走简化路径，直接扫，不进批处理流程。但官方也明确承认，这类回退场景没有被完全消除——对象图极度稀疏时，Green Tea 仍可能略慢于老 GC。这是它唯一诚实标注的软肋，第 6.5 节我们会把它构造出来复现。

3.6 手算一个例子

官方博客里有一张图，用数字说话最清楚。假设堆上有 7 个存活对象，分布在 3 个页里：

页 A: [a1] [a2] [a3]
页 B: [b1] [b2]
页 C: [c1] [c2]

引用关系: root → a1 → b1 → a2 → c1 → a3 → b2 → c2

老 GC 的扫描序列（跟着指针跑）：

A → B → A → C → A → B → C      共 7 次独立扫描，6 次跨页跳转

Green Tea 的扫描序列（攒够再扫）：

取 A，扫 a1        → 发现 b1，标记，B 入队
取 B，扫 b1        → 发现 a2，标记，A 重新入队
取 A，扫 a2, a3    → （a3 此时已被标记）连续扫两个
取 C，扫 c1, c2    → 连续扫两个
                    共 4 次扫描，其中 2 次是页内连续

7 次跳跃 vs 4 次扫描。而且这还是个玩具规模——真实堆里一页可能有 256 个对象，攒批的效果会剧烈放大。

四、架构分析：动了什么，没动什么

搞清楚边界，才知道升级的风险面在哪。

4.1 没有动的部分（这是升级敢默认开的底气）

• 三色不变式：仍然是并发标记，仍然靠写屏障维持不变式。
• 混合写屏障（Dijkstra 插入屏障 + Yuasa 删除屏障，Go 1.8 引入）：语义完全不变。
• GC pacer：什么时候触发 GC、目标堆大小怎么算、GOGC / GOMEMLIMIT 的语义——全不变。
• STW 阶段：仍然是两次极短 STW（开启标记 / 标记终止）。
• 清扫（sweep）：基本没动，它本来就只占 10%。
• finalizer / weak pointer / cleanup 语义：不变。
• Go 1 兼容性承诺：不需要改一行业务代码。

所以从「行为正确性」角度，这次升级的风险面比大多数人以为的小得多。它改的是同一个算法的执行方式，不是算法语义。

4.2 动了的部分

多出来的 1 bit/对象是有内存成本的，但相对堆本身可以忽略（对 32 字节对象来说是 1/256 的额外元数据）。

4.3 为什么 STW 不变，但 CPU 降了？

这是很多人第一反应会问错的地方：Green Tea 不缩短 STW，也不直接缩短 GC 的 wall time。

它降的是并发标记阶段占用的 CPU。并发标记是和你的业务 goroutine 抢 CPU 的（默认目标 25% CPU 用于 GC，即 GOGC 体系下的 mark assist + 后台 marker）。

所以收益的传导路径是：

标记阶段 cache miss 减少
  → 标记同样多的对象需要的 CPU 时间减少
  → 后台 marker 占用的 CPU 减少 + mark assist 触发减少
  → 业务 goroutine 拿到更多 CPU
  → 吞吐上升 / 尾延迟下降

特别注意 mark assist 这条链路：当分配速度太快、后台 marker 跟不上时，Go 会让分配内存的那个 goroutine 自己去干标记工作（mark assist）。这是 P99 延迟毛刺的一大来源。标记变快 → assist 债务还得快 → 毛刺变少。

这意味着：Green Tea 的收益在 P99 上可能比在平均吞吐上更明显。你如果只看 QPS 可能觉得「也就那样」，看 P99 才会发现香。

五、AVX-512 向量内核：GC 第一次真正吃到 SIMD

这是 Green Tea 最漂亮的部分，也是「以页为单位」这个决策带来的衍生红利——一开始可能都不是设计目标。

5.1 入场券：等大对象 ⇒ 规整元数据

传统 GC 想向量化是不可能的：每个对象大小不同、指针位图长度不同、字段偏移不同。SIMD 要求规整，而对象图天生不规整。

Green Tea 的页内视图完全不同：

• 一个 8 KiB 页 = 1024 个 8 字节的 word；
• 页内对象等大，假设 size class 是 16 字节 → 512 个对象 → 512 个 seen bit，正好一个 AVX-512 寄存器（zmm）；
• 指针位图：1024 个 word → 1024 bit → 正好两个 zmm 寄存器；
• 而且同一 size class 的所有对象共享同一份类型指针位图。

这个尺寸吻合程度好到有点像天意。

5.2 扫描内核的五步流水

官方描述的核心步骤，翻译成人话：

输入: seenBits (每对象 1 bit), scannedBits (每对象 1 bit), ptrMask (每 word 1 bit)

① load:    把 seenBits、scannedBits 整个装进向量寄存器
② andnot:  todo = seen &^ scanned          // 一条指令算出整页欠的活
③ expand:  把 todo 的「每对象 1 bit」展开成「每 word 1 bit」
           （一个 S 字节的对象要展开成 S/8 个连续 bit）
④ and:     targets = expandedTodo & ptrMask // 精确定位所有需要追的指针位置
⑤ gather:  按 targets 里的 1 bit 位置，批量读出指针值，写进输出缓冲区

整个过程几乎全在寄存器里完成，每轮循环处理 64 字节。没有分支预测失败，没有随机访存，没有依赖链。这和老 GC 的「读一个指针、跳一次、再读」是两个世界。

5.3 VGF2P8AFFINEQB：整个内核里最秀的一手

第 ③ 步「bit 展开」是最难用普通指令高效实现的。朴素做法要循环移位，慢得离谱。

Go 用的是 VGF2P8AFFINEQB——来自 x86 的 GFNI（Galois Field New Instructions）扩展，本来是给 AES/纠错码这类伽罗瓦域运算准备的。

它干的事情，数学上是：对每个字节，做一次 GF(2) 上的 8×8 矩阵-向量乘法，再加一个常数向量。

对每个 byte b（看作 GF(2) 上的 8 维列向量）:
    result_byte = A · b ⊕ c
其中 A 是一个 8×8 的 bit 矩阵，c 是 8 bit 常数

关键洞察：在 GF(2) 上，矩阵乘法就是「选取并异或若干输入 bit」。 如果矩阵 A 的第 i 行只有第 j 列是 1，那么输出的第 i 个 bit 就等于输入的第 j 个 bit——这就是任意 bit 置换。如果多行都指向同一个输入列，那就是bit 复制。

而「把 1 个对象 bit 展开成 S/8 个 word bit」恰恰就是 bit 复制。所以：

• 给定 size class，展开矩阵 A 是常量（编译期/初始化时就能算好）；
• 一条指令，几个 cycle，搞定 8 个字节内的全部展开；
• 配上 512 bit 宽度，一次处理 64 字节的元数据。

这一手能成立，完全依赖「页内对象等大」这个前提。没有 Green Tea 的页化改造，VGF2P8AFFINEQB 在 GC 里根本无从下手。

5.4 硬件门槛与降级路径

这里有个非常现实的问题，很多文章不提：

结论很重要：官方说的「额外再降约 10%」是只有较新 amd64 CPU 才有的。如果你的生产环境是 Graviton 或者国产 arm 服务器，你能拿到的是页扫描的局部性红利（也就是那个 10%~40% 的主体），但拿不到向量那一层。

所以：在 M 系列 Mac 上测出来的数，不能直接外推到 Zen 4 服务器上，反之亦然。 基准测试一定要在目标硬件上做。

六、代码实战：怎么量化你自己的收益

理论讲完了。下面是你今天下午就能跑的东西。

6.1 先确认 Green Tea 到底开没开

Go 1.26 默认开启，但你的构建可能被 CI 里某个祖传环境变量关掉了。查法：

# 看二进制的构建设置。GOEXPERIMENT 只有非默认值才会出现在这里
go version -m ./yourapp | grep -i experiment

# 什么都没输出 = 用的是默认配置 = Green Tea 开着
# 输出 build GOEXPERIMENT=nogreenteagc = 被人关了

程序里也能查：

package main

import (
	"fmt"
	"runtime/debug"
)

func main() {
	bi, ok := debug.ReadBuildInfo()
	if !ok {
		return
	}
	for _, s := range bi.Settings {
		switch s.Key {
		case "GOEXPERIMENT", "GOARCH", "GOAMD64", "-gcflags":
			fmt.Printf("%s = %q\n", s.Key, s.Value)
		}
	}
}

顺带说一句：GOAMD64 也值得关注。如果你的构建是 GOAMD64=v1（默认），编译器生成的业务代码不会用 AVX-512，但运行时的 GC 扫描内核是运行时动态检测 CPU 特性的，两者是独立的。别把它们搞混。

6.2 用 runtime/metrics 量化 GC CPU 占比（可直接抄）

GODEBUG=gctrace=1 输出人眼友好但不好聚合。生产环境请用 runtime/metrics，这是唯一官方承诺稳定的指标接口。

// gcstat/gcstat.go
package gcstat

import (
	"fmt"
	"runtime/metrics"
	"time"
)

const (
	mGCCPU   = "/cpu/classes/gc/total:cpu-seconds"
	mAllCPU  = "/cpu/classes/total:cpu-seconds"
	mCycles  = "/gc/cycles/total:gc-cycles"
	mScanAll = "/gc/scan/total:bytes"   // 每轮 GC 需要扫描的总字节（堆+栈+全局）
	mScanHp  = "/gc/scan/heap:bytes"
	mLive    = "/gc/heap/live:bytes"
	mPauses  = "/gc/pauses:seconds"     // Float64Histogram
	mGorout  = "/sched/goroutines:goroutines"
)

var names = []string{mGCCPU, mAllCPU, mCycles, mScanAll, mScanHp, mLive, mPauses, mGorout}

// Snapshot 是某一时刻的原始读数
type Snapshot struct {
	Wall      time.Time
	GCCPUSec  float64
	AllCPUSec float64
	Cycles    uint64
	ScanTotal uint64
	ScanHeap  uint64
	Live      uint64
	Goroutine uint64
	PauseP99  float64
	PauseMax  float64
}

func Take() Snapshot {
	s := make([]metrics.Sample, len(names))
	for i, n := range names {
		s[i].Name = n
	}
	metrics.Read(s)

	snap := Snapshot{Wall: time.Now()}
	for _, x := range s {
		switch x.Value.Kind() {
		case metrics.KindFloat64:
			switch x.Name {
			case mGCCPU:
				snap.GCCPUSec = x.Value.Float64()
			case mAllCPU:
				snap.AllCPUSec = x.Value.Float64()
			}
		case metrics.KindUint64:
			switch x.Name {
			case mCycles:
				snap.Cycles = x.Value.Uint64()
			case mScanAll:
				snap.ScanTotal = x.Value.Uint64()
			case mScanHp:
				snap.ScanHeap = x.Value.Uint64()
			case mLive:
				snap.Live = x.Value.Uint64()
			case mGorout:
				snap.Goroutine = x.Value.Uint64()
			}
		case metrics.KindFloat64Histogram:
			if x.Name == mPauses {
				h := x.Value.Float64Histogram()
				snap.PauseP99 = quantile(h, 0.99)
				snap.PauseMax = maxBucket(h)
			}
		case metrics.KindBad:
			// 该 Go 版本不支持这个指标名，忽略即可
		}
	}
	return snap
}

// Delta 返回两次快照之间的窗口统计
type Delta struct {
	Window     time.Duration
	GCCPUFrac  float64 // GC 占总 CPU 的比例，这是最重要的一个数
	Cycles     uint64
	ScanPerGC  uint64  // 平均每轮 GC 扫描的字节数
	LiveEnd    uint64
	PauseP99   float64
}

func Diff(a, b Snapshot) Delta {
	dGC := b.GCCPUSec - a.GCCPUSec
	dAll := b.AllCPUSec - a.AllCPUSec
	dCyc := b.Cycles - a.Cycles

	d := Delta{
		Window:   b.Wall.Sub(a.Wall),
		Cycles:   dCyc,
		LiveEnd:  b.Live,
		PauseP99: b.PauseP99,
	}
	if dAll > 0 {
		d.GCCPUFrac = dGC / dAll
	}
	if dCyc > 0 {
		d.ScanPerGC = (b.ScanTotal - a.ScanTotal) / dCyc
	}
	return d
}

func (d Delta) String() string {
	return fmt.Sprintf(
		"window=%v gc_cpu=%.2f%% cycles=%d scan_per_gc=%.1fMiB live=%.1fMiB pause_p99=%.3fms",
		d.Window.Round(time.Millisecond),
		d.GCCPUFrac*100,
		d.Cycles,
		float64(d.ScanPerGC)/(1<<20),
		float64(d.LiveEnd)/(1<<20),
		d.PauseP99*1000,
	)
}

// ---- histogram helpers ----

func quantile(h *metrics.Float64Histogram, q float64) float64 {
	var total uint64
	for _, c := range h.Counts {
		total += c
	}
	if total == 0 {
		return 0
	}
	target := uint64(float64(total) * q)
	var cum uint64
	for i, c := range h.Counts {
		cum += c
		if cum >= target {
			// Buckets 比 Counts 多一个元素；用上界作为该桶的代表值
			ub := h.Buckets[i+1]
			if isInf(ub) {
				return h.Buckets[i] // 最后一个桶上界是 +Inf，退回下界
			}
			return ub
		}
	}
	return 0
}

func maxBucket(h *metrics.Float64Histogram) float64 {
	for i := len(h.Counts) - 1; i >= 0; i-- {
		if h.Counts[i] > 0 {
			ub := h.Buckets[i+1]
			if isInf(ub) {
				return h.Buckets[i]
			}
			return ub
		}
	}
	return 0
}

func isInf(f float64) bool { return f > 1e300 || f < -1e300 }

用法：

func main() {
	before := gcstat.Take()
	runYourWorkload()          // 压测 / 真实流量
	after := gcstat.Take()
	fmt.Println(gcstat.Diff(before, after))
}

盯这三个数：

这张表很关键：如果你看到 scan_per_gc 有明显变化，说明你的对比实验里混入了别的变量（比如两次运行的负载不一样），结论不可信。scan_per_gc 是你的对照组指纹，必须先确认它稳定，gc_cpu 的对比才有意义。

6.3 gctrace 怎么读（快速定性用）

GODEBUG=gctrace=1 ./yourapp 2>&1 | grep '^gc '

输出长这样：

gc 14 @3.201s 4%: 0.11+82+0.033 ms clock, 1.7+31/163/0+0.53 ms cpu, 412->418->209 MB, 424 MB goal, 0 MB stacks, 0 MB globals, 16 P

拆解：

• 4% ← 这就是自程序启动以来 GC 占总 CPU 的累计比例，最该盯的数
• 0.11+82+0.033 ms clock ← STW标记开始 + 并发标记 + STW标记终止（wall time）
• 1.7+31/163/0+0.53 ms cpu ← 对应的 CPU 时间。中间那组 31/163/0 是：mark assist / 后台 marker / 空闲时间 marker
• 412->418->209 MB ← GC 开始堆大小 → 结束堆大小 → 存活堆大小

重点看 31/163/0 里的第一个数（mark assist）。 这个数越大，说明业务 goroutine 被拉去干 GC 活的时间越多，P99 越难看。Green Tea 让标记变快之后，这个数应该显著下降。很多人只看 4% 那个总数，错过了收益最明显的地方。

6.4 A/B 对照脚本

#!/usr/bin/env bash
set -euo pipefail

PKG=${1:-./...}
COUNT=${2:-10}

echo ">>> Green Tea (default)"
go test -run '^$' -bench . -benchmem -count "$COUNT" "$PKG" | tee /tmp/gt.txt

echo ">>> Legacy GC"
GOEXPERIMENT=nogreenteagc \
  go test -run '^$' -bench . -benchmem -count "$COUNT" "$PKG" | tee /tmp/nogt.txt

echo ">>> diff (baseline=legacy)"
go tool benchstat /tmp/nogt.txt /tmp/gt.txt

几个必须注意的坑：

1. -count 10 起步，GC 行为方差很大，跑一次的数字毫无意义。
2. 锁频率：sudo cpupower frequency-set -g performance，否则你测的是温度墙。
3. 固定 GOGC 和 GOMAXPROCS：GOGC=100 GOMAXPROCS=8，别让两组跑在不同的堆目标上。
4. GOEXPERIMENT 会触发标准库重编译，第一次跑会慢，先 warm 一次再计时。
5. 微基准会低估收益。Green Tea 的红利依赖「页里攒够对象」，小堆的微基准攒不满。服务级压测的数字才作数。

6.5 构造反例：让 Green Tea 变慢

前面说了，稀疏对象图是 Green Tea 的软肋。我们把它做出来：

// sparse_test.go
package sparse

import (
	"runtime"
	"testing"
)

type payload struct {
	id  int64
	ref *box    // 必须有指针字段，否则会被判定成 noscan，根本不进扫描流程
	pad [40]byte
}

type box struct{ v int64 }

// keepEvery=1  → 每个对象都存活，页内密集
// keepEvery=64 → 每 64 个才留 1 个，页内极稀疏
func build(total, keepEvery int) []*payload {
	kept := make([]*payload, 0, total/keepEvery+1)
	for i := 0; i < total; i++ {
		p := &payload{id: int64(i), ref: &box{v: int64(i)}}
		if i%keepEvery == 0 {
			kept = append(kept, p)
		}
	}
	return kept
}

func benchN(b *testing.B, keepEvery int) {
	const total = 1 << 21
	live := build(total, keepEvery)
	runtime.GC() // 让上面的垃圾先清掉，只留稳定的存活集
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		runtime.GC() // 直接测一次完整 GC 的成本
	}
	b.StopTimer()
	runtime.KeepAlive(live)
}

func BenchmarkDense(b *testing.B)  { benchN(b, 1) }
func BenchmarkSparse8(b *testing.B) { benchN(b, 8) }
func BenchmarkSparse64(b *testing.B) { benchN(b, 64) }

跑 6.4 那个 A/B 脚本，你大概率会看到：

• Dense：Green Tea 明显赢；
• Sparse64：差距收窄，甚至 Green Tea 略输。

注意 keepEvery=64 这个 case 在真实世界并不罕见：典型场景是「批量创建对象、只保留少数进缓存、其余全丢」的流水线，比如日志解析、批量导入、爬虫管道。这类代码升级后如果没看到收益，别怀疑人生，你可能就撞上了这个模式。

但更重要的是：这个反例本身就告诉你该怎么改——把「散着 new、稀疏存活」改成「批量分配、集中存活」，你不但绕开了反例，还能吃到更大的红利。这正是下一节的主题。

七、性能优化：Green Tea 时代的七条写码规律

这是全文最有实操价值的部分。

先立个总纲：GC 的工作量 ≈ 存活对象数 × 每个对象的指针字段数。 Green Tea 把「访问这些指针的单位成本」降下来了，但没有减少要访问的指针数量。想吃更大的收益，你得从分子下手。

规律 1：减少「指针数量」比减少「对象数量」更值钱

一个 noscan 对象（不含任何指针的对象，比如 []byte、[]int64、纯数值 struct）根本不会被标记器扫描内容——运行时在 span 级别就知道这一整页都不需要扫。

所以：

// 差：1000 万个对象，每个 2 个指针 → 2000 万次指针追逐
type Point struct {
	Name *string
	Tags *[]string
	X, Y float64
}
points := make([]*Point, 10_000_000)

// 好：整个数组是 1 个 noscan 对象 → GC 扫描成本约等于 0
type PointFlat struct {
	NameOff, NameLen int32   // 指向共享 blob 的偏移
	TagsOff, TagsLen int32
	X, Y             float64
}
points := make([]PointFlat, 10_000_000) // 无指针字段 → noscan
blob   := make([]byte, 0, 1<<26)        // 无指针 → noscan

后者的 GC 扫描成本从「两千万次随机访存」变成「两个 slice header」。这不是 10%~40% 的改进，是三个数量级。

代价是你要自己管理 blob 的生命周期和字符串切片，代码变丑。只在真正的热点数据结构上这么干，别到处滥用。

规律 2：[]T 优于 []*T

orders := make([]Order, n)   // 1 次分配，1 个对象，连续内存
orders := make([]*Order, n)  // n+1 次分配，n+1 个对象，内存位置随机

[]*Order 的问题不只是分配多：

• GC 要把 slice 里的 n 个指针逐个追出去；
• 这 n 个 Order 在堆上的位置由分配时机决定，可能横跨成百上千个页；
• 每一页只有零星几个存活对象 → 正好落进 6.5 节的反例。

[]Order 则是一整块连续内存。即使 Order 内部有指针字段，GC 也是顺序线性扫这块内存，是 stride pattern，预取器全程有效。

什么时候不得不用 []*T？元素需要独立生命周期、或者元素很大且需要频繁在容器间移动。其余情况一律优先 []T。

规律 3：用 slab 让同类对象落在同一页

如果你确实需要独立的 *T，至少让它们在内存里挨着：

// slab.go
package slab

const chunkSize = 1024

type Slab[T any] struct {
	chunk []T
	next  int
}

func (s *Slab[T]) New() *T {
	if s.next >= len(s.chunk) {
		s.chunk = make([]T, chunkSize) // 一次性拿一大块
		s.next = 0
	}
	p := &s.chunk[s.next]
	s.next++
	return p
}

这样连续 New() 出来的 1024 个对象保证物理相邻，Green Tea 一次出队就能把它们全扫了。

必须警告的副作用：整个 chunk 的生命周期被最长寿的那个元素绑死。如果 1024 个里只有 1 个还活着，剩下 1023 个的内存也释放不掉。

所以 slab 只适用于生命周期高度一致的对象：

• ✅ 一次请求内的临时对象（请求结束整体丢弃）
• ✅ 一次编译/解析产生的 AST 节点
• ✅ 一次批处理的中间结果
• ❌ 长期缓存里的条目（生命周期各异，会造成严重内存放大）

规律 4：用 handle（int32 索引）替代指针

这是把规律 1 推到极致。经典场景是树、图、AST：

// 传统写法：GC 要遍历整棵树
type Node struct {
	Left, Right *Node
	Key         int64
	Val         string
}

// handle 写法：整棵树对 GC 来说只有 2 个指针
type NodeID int32

const NilNode NodeID = -1

type Node struct {
	Left, Right    NodeID // int32，不是指针
	Key            int64
	ValOff, ValLen int32  // 指向 blob
}

type Tree struct {
	nodes []Node // noscan
	blob  []byte // noscan
}

func (t *Tree) Get(id NodeID) *Node {
	return &t.nodes[id]
}

func (t *Tree) Val(id NodeID) string {
	n := &t.nodes[id]
	// 注意：这里做了 unsafe-free 的子串引用，blob 不能被并发修改
	return string(t.blob[n.ValOff : n.ValOff+n.ValLen])
}

func (t *Tree) Alloc() NodeID {
	t.nodes = append(t.nodes, Node{Left: NilNode, Right: NilNode})
	return NodeID(len(t.nodes) - 1)
}

一棵 1000 万节点的树，GC 扫描成本从「1000 万次指针追逐」变成「2 个 slice header」。

代价清单（要诚实地列出来）：

• 类型安全变弱，NodeID 用错了编译器不管；
• 不能用 nil 判空，要用哨兵值；
• append 扩容会让之前拿到的 *Node 失效（这是最容易踩的坑，所以 Get 返回的指针不能跨 Alloc 持有）；
• 调试体验变差，dlv 里看不到树形结构。

这是典型的用可维护性换性能。 只在 profile 明确指出 GC 是瓶颈、且这个结构确实是大头时才上。

规律 5：map 的键值去指针化

map 是 GC 的重灾区，因为它的 bucket 数组会被完整扫描：

map[string]*User      // 最差：key 有指针(string header)，value 是指针
map[string]User       // 中等：value 内联，但 key 的 string 仍需扫描
map[int64]User        // 好：key 是 noscan
map[int64]int32       // 最好：整个 map 的 bucket 是 noscan，GC 完全不看

实战改法：把字符串 key 换成哈希后的 uint64 + 一个 slice 存原串做冲突校验：

type StringTable struct {
	idx  map[uint64]int32 // noscan bucket
	offs []int32          // noscan
	blob []byte           // noscan
}

Go 1.24 之后 map 换成了 Swiss Table 实现，内存布局更紧凑，但**「bucket 里有没有指针」这条规律依然成立**。

规律 6：sync.Pool 是补充，不是替代

很多人以为 sync.Pool 能解决 GC 问题。要点清楚：

• sync.Pool 减少的是分配次数（降低 GC 频率）；
• Green Tea 优化的是单轮 GC 的标记成本；
• 两者正交，可以叠加。

但注意：sync.Pool 里的对象在 GC 时是存活的（至少活到下一轮 GC 清空 Pool），所以它反而增加了存活集大小。如果你 Pool 里放的是含大量指针的复杂对象，可能得不偿失。

Pool 里优先放 noscan 的东西（[]byte buffer、bytes.Buffer），这是最安全的用法。

规律 7：重新标定 GOGC / GOMEMLIMIT

Green Tea 让标记变便宜了，这在参数空间里意味着什么？

GC 的成本大致是：

GC 总开销 ≈ GC 频率 × 单轮标记成本
GC 频率   ≈ 分配速率 / (存活堆 × GOGC/100)

单轮标记成本降了 10%~40% → 同样的 CPU 预算下，你可以负担更高的 GC 频率 → 可以调低 GOGC → 换来更小的内存占用。

如果你的服务是内存受限（容器 limit 卡得紧），这是个实打实的机会：

# 升级前：GOGC=200，堆峰值 4GB
# 升级后可以尝试：GOGC=150 甚至 120，堆峰值降到 3GB，GC CPU 持平

反过来，如果你是 CPU 受限、内存宽裕，就保持 GOGC 不变，直接收 CPU 红利。

务必同时设 GOMEMLIMIT（Go 1.19+ 的软内存上限），它是防 OOM 的最后一道闸：

import "runtime/debug"

func init() {
	// 容器 limit 的 85%~90%，留出非堆内存（栈、mmap、cgo）的空间
	debug.SetMemoryLimit(int64(float64(containerLimitBytes) * 0.85))
}

落地方法论：三层验证，一层都别跳

我见过太多「升级后没效果」的结论，是因为只做了第一层：

L1 的作用是排除回归，不是证明收益。 真正的数字必须来自 L2/L3。

八、和 Green Tea 一起看才完整：Go 1.26 的其余运行时改动

Green Tea 不是孤立的。1.26 这一版的运行时改动串起来看，能看出新领导团队（Austin Clements 任技术负责人、Cherry Mui 任 Go 核心负责人后的第一个正式版本）的清晰意图。

8.1 goroutine 泄漏 profile：原理和 GC 是同一套

这是我认为 1.26 里被低估最严重的特性。

GOEXPERIMENT=goroutineleakprofile go build -o app .
./app
# 然后访问
curl localhost:6060/debug/pprof/goroutineleak

它的原理和 Green Tea 共用同一套可达性分析，逻辑极其漂亮：

如果 goroutine G 阻塞在同步原语 P（channel / Mutex / Cond）上，而 P 从任何可运行的 goroutine 都不可达，那么 P 永远不可能被唤醒，G 就永远醒不过来 —— 这就是泄漏。

这是一个判定性结论，不是启发式猜测。对比一下你现在的排查方式：/debug/pprof/goroutine 给你一堆 goroutine 栈，你得自己肉眼判断哪个是「应该阻塞的」哪个是「泄漏的」。

最经典的泄漏模式：

// 典型泄漏：无缓冲 channel + 提前 return
func process(ws []Work) (Result, error) {
	ch := make(chan Result) // 无缓冲！
	for _, w := range ws {
		go func(w Work) {
			r, err := doWork(w)
			if err != nil {
				return // 这个 goroutine 直接走了，但主流程还在等
			}
			ch <- r // 如果主流程已经 return，这里永远阻塞 → 泄漏
		}(w)
	}
	for range ws {
		r := <-ch
		if r.Bad {
			return Result{}, errors.New("bad") // 提前 return，剩下的 goroutine 全卡死
		}
	}
	return merge(), nil
}

修法（两种，都写一下）：

// 修法 A：给 channel 加足够的缓冲，发送方永不阻塞
ch := make(chan Result, len(ws))

// 修法 B：用 context 让发送方可以放弃
func process(ctx context.Context, ws []Work) (Result, error) {
	ctx, cancel := context.WithCancel(ctx)
	defer cancel() // 无论怎么退出，都通知所有 worker

	ch := make(chan Result, len(ws))
	for _, w := range ws {
		go func(w Work) {
			r, err := doWork(w)
			if err != nil {
				return
			}
			select {
			case ch <- r:
			case <-ctx.Done(): // 主流程走了，我也不等了
			}
		}(w)
	}
	// ...
}

这个特性的理论来自 Uber 的 Vlad Saioc 发表的学术工作，Go 团队称实现已经生产就绪，只是 API 还在收集反馈，目标是 1.27 默认开启。建议现在就在测试环境和预发环境挂上。

8.2 simd / archsimd 实验包

GOEXPERIMENT=simd go build ./...

提供架构相关的 SIMD 类型和操作，目前 amd64 可用，支持 128/256/512 bit 向量类型（如 Int8x16、Float64x8）和对应操作。

这和 Green Tea 是同一条技术线的两个出口：运行时自己先用 AVX-512 把 GC 内核写了，验证了这条路，然后把能力开放给用户代码。API 目前不稳定，官方计划后续做一个可移植的高层 SIMD 包。

现在别在生产用，但如果你写向量检索、图像处理、编解码，值得开始做技术预研。

8.3 runtime/secret：前向保密的运行时支持

GOEXPERIMENT=runtimesecret go build ./...

处理完密钥这类敏感数据后，主动擦除寄存器、栈、堆上的临时副本。目前支持 linux/amd64 和 linux/arm64。

意义在于：Go 之前做不到可靠擦除——你 for i := range key { key[i] = 0 }，编译器可能优化掉；GC 可能已经把副本挪走了；寄存器里的残留你根本碰不到。现在这是运行时级别的能力。

对金融、支付、密钥管理类服务来说，这是能写进合规文档的东西。

8.4 cgo 基线开销降低约 30%

如果你的服务重度依赖 cgo（SQLite、图像库、国密库、各种 C SDK），这条的收益可能比 Green Tea 还大。

cgo 调用的固定开销来自：切换到系统栈、通知调度器「这个 M 要进入 syscall 状态」、返回时重新绑定 P。降 30% 意味着你之前为了避开 cgo 而做的批处理封装，有些可以简化了。

但仍然记住：cgo 调用依然比纯 Go 调用贵一到两个数量级，「30% 优化」不改变「循环里别调 cgo」这条铁律。

8.5 编译器：更多切片能栈分配

编译器现在能在更多情况下把 slice 的后备存储分配到栈上。这直接减少堆压力 → 减少 GC 频率，和 Green Tea 是乘法关系。

如果怀疑这个优化引入了 bug：

# 用 bisect 定位到具体是哪个分配点出的问题
bisect -compile=variablemake go test ./...

# 或者全局关掉新的栈分配行为
go build -gcflags=all=-d=variablemakehash=n ./...

配合逃逸分析看效果：

go build -gcflags='-m -m' ./... 2>&1 | grep 'does not escape'

8.6 64 位平台堆基址随机化

默认开启，让攻击者更难预测堆地址（主要防的是 cgo 场景下的内存破坏漏洞被稳定利用）。

# 临时禁用（不建议，预计未来版本会强制开启）
GOEXPERIMENT=norandomizedheapbase64 go build ./...

注意副作用：如果你的测试里有任何依赖地址稳定性的断言（比如把指针值当 map key 打日志再比对、或者依赖 fmt.Sprintf("%p") 的输出稳定），会开始 flaky。这类代码本来就是错的，正好借这个机会修掉。

8.7 新的调度器指标

runtime/metrics 新增了一批调度器指标：

• /sched/goroutines/... 前缀下的各状态 goroutine 计数
• /sched/threads:threads——运行时知道的 OS 线程数
• /sched/goroutines-created:goroutines——累计创建的 goroutine 总数

最后这个特别有用：goroutines-created 的斜率就是 goroutine 创建速率。配合当前存活数一起看：

存活数平稳 + 创建速率高  → 正常的短生命周期 worker
存活数上涨 + 创建速率高  → 大概率泄漏，去开 8.1 的 leak profile
存活数上涨 + 创建速率低  → 阻塞，去看 mutex/block profile

这三行判据建议直接做成监控看板的告警规则。

九、十条踩坑清单

按我认为的「踩到概率 × 后果严重度」排序：

1. 在 arm64 上测完就下结论。 向量内核目前只有 amd64（Ice Lake / Zen 4 及更新）。M 系列 Mac 上的数字外推到 Zen 4 服务器会低估，反过来会高估。基准测试必须在目标硬件上做。

2. 用微基准证明「没收益」。 小堆攒不满页，Green Tea 的批处理红利出不来。微基准只能用来排除回归，不能用来度量收益。

3. 只看平均吞吐，不看 P99。 Green Tea 最大的收益点之一是减少 mark assist（业务 goroutine 被拉去干 GC 活），这体现在尾延迟上。看 gctrace 里 a/b/c ms cpu 的第一个数。

4. 忘了 CI 里那行祖传的 GOEXPERIMENT。 很多团队为了 Go 1.25 时期测试 Green Tea 加过环境变量，升到 1.26 后忘了删 nogreenteagc，白升级。go version -m 查一下，两秒钟的事。

5. 依赖 nogreenteagc 做长期兜底。 这个 opt-out 开关预计在 Go 1.27 移除。如果你现在因为回退而关掉它，请立刻去 golang/go 提 issue（带上可复现的 benchmark），而不是当成永久方案。

6. 期待 STW 变短。 不会。Green Tea 降的是并发标记的 CPU 占用。如果你的痛点是 STW 毛刺，方向应该是减少栈扫描量（少开 goroutine、栈别太深）和减少 finalizer。

7. slab 用错场景导致内存放大。 生命周期不一致的对象放同一个 slab，1 个存活元素会钉住整块 chunk。上 slab 前先确认生命周期一致性。

8. handle 化之后持有失效指针。 append 扩容会让之前的 &t.nodes[i] 变成野指针（指向旧数组，值是旧的）。规矩：Get 返回的指针，不允许跨越任何可能触发 Alloc 的调用。这个 bug 极难查，因为它不 panic，只是读到脏数据。

9. 升级同时改 GOGC，然后归因错。 一次只动一个变量。先升级、测出基线，再调 GOGC、再测。两个一起动，出了问题你分不清是谁的锅。

10. 忽略 1.26 的其他破坏性变更。 这版还有几个容易咬人的：net/http/httputil.ReverseProxy.Director 被废弃（有安全问题，改用 Rewrite）；net/url.Parse 开始拒绝 host 里带裸冒号的畸形 URL（urlstrictcolons=0 可临时恢复）；crypto 系列的 GenerateKey/Sign 不再接受传入的 random 参数（确定性测试改用 testing/cryptotest.SetGlobalRandom）；image/jpeg 换了新实现，输出可能不再 bit-for-bit 一致（如果你的测试在比对图片哈希，会红）。

十、总结与展望

这次改动真正的价值是什么

一句话：Green Tea 把 GC 标记从「图算法问题」重新定义成了「内存布局问题」。

老 GC 的心智模型是「遍历一张图」，优化方向是「减少要遍历的节点」。Green Tea 的心智模型是「按页扫描一片规整的内存」，优化方向变成了「让 CPU 的访存流水线跑满」。

这个视角切换带来的连锁反应：

• 队列语义从 LIFO 变 FIFO（因为要攒批）；
• 元数据从 1 bit 变 2 bit（因为要分离「发现」和「扫描」）；
• SIMD 从「完全不可能」变成「一条 VGF2P8AFFINEQB 搞定」（因为页内对象等大）。

没有哪一步是天才灵感。核心想法早在 2018 年就有了——有趣的是团队里没人记得是谁最先提出的，大家都以为是别人的主意。2024 年 Austin Clements 在日本喝抹茶时做出了原型（GC 代号 "Green Tea" 由此而来），2025 年 Michael Knyszek 完成生产化实现。中间是八年的失败中间方案清单。官方博客里那张时间线图，列满了被放弃的尝试。

这才是真实的系统工程：想法很便宜，把想法做到能在 Google 全量生产环境跑，才是那 99%。

对你的建议，按优先级排

1. 今天就升级 1.26，白嫖 10%~40% 的 GC 开销下降，零代码改动。
2. 接上 6.2 的 runtime/metrics 采集，把 gc_cpu 占比做成常驻监控。没有度量就没有优化——这句话在 GC 领域尤其真。
3. 开 GOEXPERIMENT=goroutineleakprofile 挂到测试/预发环境。 这个特性的排障价值可能超过 GC 优化本身，而且 1.27 就要默认开了，早用早受益。
4. 然后，也是最重要的：拿 profile 找出你的存活集大头，按第 7 节的七条规律改数据布局。 运行时能给你 10%~40%，数据布局能给你 10 倍。运行时优化是别人送你的，数据布局是你自己能挣的。

往前看

Go 1.27 的两条明牌：nogreenteagc 退出开关移除（Green Tea 成为唯一实现），goroutine leak profile 目标默认开启。

更值得关注的是 SIMD 那条线。simd/archsimd 实验包 + 运行时里已经落地的 AVX-512 扫描内核，说明 Go 团队已经建立起了「在运行时和标准库里用向量指令」的工程能力和信心。arm64 的向量内核（NEON/SVE）大概率是下一步。

再往远看，Green Tea 证明了一件事：Go 运行时还有大量「因为历史设计而没吃到的现代硬件红利」。调度器的 NUMA 感知、分配器的向量化、栈扫描的批处理……这些方向此刻应该都在某个人的 proposal 草稿里。

对我们写业务的人来说，结论朴素得有点无聊，但确实是这样：

升级版本是最便宜的优化。但真正拉开差距的，永远是你怎么组织数据。

八年时间，Go 团队把「追着对象跑」改成了「把一页里的事做完再走」。你的代码里，是不是也有一堆「追着对象跑」的地方？