Go 的垃圾回收到底在忙什么

一篇讲人话的 GC 入门。文中所有 gctrace、基准测试、逃逸分析的输出，都是在 Go 1.26.3 / darwin-arm64 / Apple M4 上真实跑出来的，不是手写示意。

你大概率没写过一行跟 GC 有关的代码，但它一直在你的程序里干活。这篇文章想把三件事讲清楚：

1. Go 的 GC 是怎么判断一个对象还有没有用的；
2. 程序在跑、指针在变，它怎么保证不误杀；
3. 什么时候你需要动手调它，怎么调。

1. 先问一句：为什么需要 GC

在 C 里，内存要自己还：

char *buf = malloc(1024);
// ... 用 buf ...
free(buf);

这行 free 写错位置，就是两类经典事故：

• 忘了写 → 内存泄漏。进程越跑越胖，最后被 OOM Killer 干掉。
• 写了两次，或者释放后还在用 → 野指针 / use-after-free。轻则数据错乱，重则可被利用成安全漏洞。

麻烦在于，一块内存"还有没有人用"，往往不是写 free 的那个函数能单独决定的——它可能被塞进了某个全局缓存，也可能被另一个线程持有。谁来 free 于是变成了一个需要全局视野的问题。

GC 的思路就是：既然这事需要全局视野，那就交给一个有全局视野的角色来做。程序员只管 new，不管 free。

2. Go 的答案：并发三色标记清除

一句话概括 Go 的 GC：从根出发，把能走到的对象全标记一遍，剩下没被标到的就是垃圾。

有三个关键词决定了它的性格：

并发（Concurrent）——GC 的绝大部分工作和你的业务代码同时进行，而不是"停下全世界慢慢扫"。这是 Go 敢在低延迟服务里用 GC 的根本原因。

非分代（Non-generational）——很多语言（Java、.NET）会赌"大部分对象都是朝生夕死的"，于是把堆分成新生代和老年代，平时只扫新生代。Go 没有这么做。Go 的选择是：靠编译器的逃逸分析，让大量短命对象根本不进堆（直接分配在栈上，函数返回就自动没了），从源头减少了分代能带来的收益。

不移动（Non-moving）——回收之后 Go 不会把存活对象挪到一起做内存压缩，对象地址从生到死不变。

一个容易混淆的点：堆上的对象不会移动，但 goroutine 的栈会。栈空间不够时，runtime 会分配一块更大的栈，把整个栈拷贝过去，再逐个修正指向栈内的指针。这是栈扩容，不是 GC 干的。

不移动带来的代价是可能产生内存碎片——不过下一节会看到，Go 的分配器结构让这个问题没那么严重。

3. 对象是从哪来的

要理解回收，得先知道分配。

Go 的分配器是三层结构，逐层加锁、逐层变慢：

绝大多数分配都在第一层就完成了，连锁都不用加。

关键在 size class：Go 把对象按大小归入约 68 个档位，一个 span 里所有格子的尺寸完全一致。所以当一个对象死掉，它腾出来的格子可以被下一个同尺寸的对象直接住进去——不需要挪动别人、不需要整理内存。这就是 Go 敢做 non-moving GC 的底气。

补充两个边界情况：小于 16 字节且不含指针的对象，会被 tiny allocator 打包塞进同一个格子；大于 32KB 的大对象则跳过前两层，直接找 mheap 要页。

4. 核心：三色标记法

现在进入正题。GC 要回答的问题是"谁还活着"，它的做法是给每个对象涂一种颜色。

三种颜色的含义是：

• 白色：还没被看到。标记结束时仍是白色的，就是垃圾。
• 灰色：已经被看到了，但它自己指向了谁，还没查。
• 黑色：它自己和它指向的所有对象，都查完了。

流程就是不断地"从灰色集合里拿一个出来处理"：

1. 开局，所有堆对象都是白色。
2. 找出根对象（goroutine 栈上的变量、全局变量、寄存器里的指针），把它们直接指到的对象涂灰。
3. 从灰色集合里取一个对象，把它指向的所有白色对象涂灰，然后把它自己涂黑。
4. 重复第 3 步，直到灰色集合为空。
5. 这时还是白色的对象，就没有任何一条从根出发的路径能到达它——回收。

灰色集合为空是整个算法的终止条件，也是"标记完成"的判据。

注意这里回收的含义：不是把内存还给操作系统，而是把那个格子在 span 里标记成"空闲"，等着下一个同尺寸的对象来住。

5. 难点：程序一边跑，指针一边变

上一节的流程有个致命的隐含前提——标记期间对象之间的引用关系不变。

可 Go 的 GC 是并发的。标记在跑的同时，你的业务代码也在跑，也在改指针。这就出事了：

看左边这个场景，两步操作凑在一起：

1. 程序把 C 挂到了已经变黑的 A 底下（A.next = C）；
2. 程序又把 B 到 C 的引用断掉了（B.next = nil）。

A 已经黑了，GC 认为它查完了，不会再回头看它。而 C 原本唯一那条"能被灰色对象走到"的路，刚刚被掐断了。于是 C 一直白着，被当成垃圾回收掉——但 A 手里还攥着它的地址。下次 A 顺着指针读过去，读到的是一块已经被别人占用的内存。

学术上把它总结成漏标的两个必要条件（两条同时成立才会出事）：

1. 黑色对象新增了一条指向白色对象的引用；
2. 该白色对象与所有灰色对象之间的可达路径全部被破坏。

破坏掉任意一条，问题就不存在了。写屏障（write barrier）就是干这个的：它是编译器在每一处堆指针赋值前后插入的一小段钩子代码，GC 期间生效。

Go 用的是混合写屏障（Go 1.8 引入），runtime 源码里的伪代码是这样：

writePointer(slot, ptr):
    shade(*slot)              // Yuasa 删除屏障：被覆盖掉的旧对象，涂灰
    if current stack is grey:
        shade(ptr)            // Dijkstra 插入屏障：新写进去的对象，涂灰
    *slot = ptr

shade 就是"如果它是白的，涂成灰的，扔进待处理队列"。删除屏障堵住了条件 2，插入屏障堵住了条件 1，两边都堵死。

有个实现细节值得一提：源码注释里明确说了，实际实现不做那个 if 判断，无条件把 ptr 也涂灰。原因不是图省事，而是"检查 slot 所在对象的颜色"需要额外的内存屏障来保证顺序，而内存屏障比多涂几个对象贵得多。

混合写屏障真正的价值

它最大的意义其实不在于"堵漏"——Go 1.8 之前的插入屏障也能堵漏。它的价值在于消灭了 STW 重新扫描栈这一步。

栈上的指针写是极高频操作，给它加屏障性能上不可接受，所以栈写不加屏障。老方案的代价是：标记结束时必须停下所有 goroutine，重新扫一遍所有栈，确认没有漏网之鱼。goroutine 一多，这一步就是实打实的毫秒级卡顿。

混合写屏障配合"GC 开始时把所有栈一次性扫黑、之后不再重扫"的策略，把这个 STW 直接删掉了。这就是 Go 的 STW 从毫秒级降到微秒级的关键一步。

6. 一轮 GC 的完整时间线

四个阶段，其中只有两小段是真正 STW 的：

关于并发标记阶段，两个细节：

GC 会拿走约 25% 的 CPU。 runtime 会启动相当于 25% × GOMAXPROCS 的专职标记 worker。也就是说 GC 忙的时候，你的服务大约还有 75% 的算力。

分配太猛的 goroutine 会被罚去干活（mark assist）。 如果标记还没跑完，你就疯狂分配新对象，那么"标记速度"永远追不上"制造垃圾的速度"。所以 runtime 给每个 goroutine 记了笔账：你分配得越多，就越可能在下一次分配时被强制先去帮忙标记一批对象。

生产上如果观察到零星的长尾延迟，mark assist 往往比 STW 更可疑——某个请求恰好在分配时被抓去当苦力了。

STW 到底多久

这是实测数据，本机跑一个每秒制造几百 MB 垃圾的程序：

gc 17 @0.054s 2%: 0.028+0.26+0.008 ms clock, ... 3->3->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 10 P
                  ~~~~~      ~~~~~
                  STW ①      STW ③

0.028 ms 和 0.008 ms，也就是 28 微秒和 8 微秒。中间那个 0.26 ms 是并发标记的耗时，那段时间业务代码是照跑的。

不过我也在同一批输出里看到过这样一行：

gc 15 @0.038s 3%: 2.7+0.49+0.018 ms clock, ...

第一段 STW 变成了 2.7 毫秒。所以"STW 都是微秒级"是均值意义上的说法，不是保证。抢占某个正在执行长循环的 goroutine、系统调度抖动，都可能让个别一轮变长。关心 P99 的话，看 /gc/pauses:seconds 这个直方图指标，比看平均值靠谱。

7. 什么时候会触发 GC

四个触发源：

① 堆涨到了目标值（最主要）

简化的公式是：

下一轮触发线 = 上一轮存活量 × (1 + GOGC/100)

GOGC 默认 100，也就是"堆涨到存活量的 2 倍就开一轮 GC"。

严格来说 pacer 还会把栈和全局变量算进去，实际公式接近 live + (live + stacks + globals) × GOGC/100。实测可以验证这一点：

/gc/heap/live:bytes    4967528     ← 存活 4.74 MiB
/gc/heap/goal:bytes    10122618    ← 目标 9.65 MiB

目标比 live × 2 多出约 183 KB，多出来的就是栈和全局那部分。

② 撞到 GOMEMLIMIT 软上限（Go 1.19+）。快到上限时，GC 会自动变得更频繁，尽量把内存压回去。

③ 两分钟没 GC 了，强制来一轮。 由 sysmon 线程盯着，源码里是 forcegcperiod = 2 * 60 * 1e9。这条兜底规则的意义是：一个几乎不分配内存的空闲服务，也不至于让上一轮的垃圾永远占着。

④ 手动调 runtime.GC()。 会阻塞到这一轮完成。

8. 实战调优

原理讲完了，下面是能直接上手的部分。

8.1 第一步永远是看数据

GODEBUG=gctrace=1：零成本，任何环境都能开

GODEBUG=gctrace=1 ./your-service

输出的每一行长这样（真实输出）：

gc 26 @0.095s 5%: 2.0+5.9+0.57 ms clock, 20+1.2/6.2/0.56+5.7 ms cpu, 4->4->2 MB, 5 MB goal, 0 MB stacks, 0 MB globals, 10 P

逐段拆开：

看这一行的顺序建议是：先看 5% 这个总占比（超过 20% 就该管了），再看 4->4->2 里最后那个存活量是不是在持续上涨（涨 = 泄漏嫌疑）。

runtime/metrics：程序内埋点，适合接监控

比 runtime.ReadMemStats 更该用这个——ReadMemStats 会 STW，metrics.Read 不会。

names := []string{
    "/gc/cycles/total:gc-cycles",
    "/gc/heap/live:bytes",
    "/gc/heap/goal:bytes",
    "/gc/gogc:percent",
    "/gc/gomemlimit:bytes",
    "/memory/classes/total:bytes",
}
samples := make([]metrics.Sample, len(names))
for i, n := range names {
    samples[i].Name = n
}
metrics.Read(samples)

实测输出：

/gc/cycles/total:gc-cycles             133
/gc/heap/live:bytes                    4967528
/gc/heap/goal:bytes                    10122618
/gc/gogc:percent                       100
/gc/gomemlimit:bytes                   9223372036854775807   ← 没设，就是 MaxInt64
/memory/classes/total:bytes            22268168

注意最后一行：Go runtime 一共向系统要了 21 MiB，而堆上存活对象只有 4.7 MiB。RSS 和堆大小从来不是一回事，中间差的是栈、span 元数据、mcache、以及已经回收但还没还给 OS 的页。排查内存问题时把这两个概念混起来，会浪费很多时间。

顺带一提铁律 14：这些指标接 Prometheus 时不要带 trace_id / uid 之类的高基数 label，GC 指标本身是进程级的，service + instance 就够了。

pprof：定位到具体是哪行代码在制造垃圾

# 谁占着内存不放（排查泄漏用这个）
go tool pprof -http=:8080 -inuse_space http://127.0.0.1:6060/debug/pprof/heap

# 谁在疯狂分配（降低 GC 压力用这个）
go tool pprof -http=:8080 -alloc_space http://127.0.0.1:6060/debug/pprof/heap

这两个视角要分清：inuse_space 看的是当前还活着的，找泄漏用；alloc_space 看的是从启动到现在累计分配过的，哪怕早就被回收了也算——降低 GC 频率要看的是这个。

8.2 两个旋钮：GOGC 和 GOMEMLIMIT

GOGC——用内存换 CPU

调大 GOGC，触发线抬高，GC 次数变少，CPU 省下来，但常驻内存变大。同一个程序实测：

差了 5 倍多。如果你的服务 gctrace 里 GC CPU 占比常年 15% 以上，而容器内存又有富余，把 GOGC 调到 200~400 通常是笔划算的买卖。

GOMEMLIMIT——防 OOM 的软上限（Go 1.19+）

GOGC 是个比例，它有个天然缺陷：存活量突然暴涨时，触发线会跟着翻倍上去，然后容器 OOM。GOMEMLIMIT 给了一条绝对的线。

GOMEMLIMIT=32MiB GOGC=off ./your-service

实测这个组合下，GC 只跑了 19 轮（默认配置是 152 轮），而且触发目标稳稳停在 25 MB，给 32 MiB 的上限留了余量：

gc 17 @0.023s 1%: 0.024+0.17+0.003 ms clock, ... 24->25->5 MB, 25 MB goal, ...

容器环境的推荐配法：

env:
  - name: GOMEMLIMIT
    value: "1800MiB"   # 容器 limit 2GiB 的 ~90%，留出非 Go 内存的余量
  - name: GOGC
    value: "200"       # 或者按需要更大

三个必须知道的坑：

1. 它是软上限，不是硬上限。 如果存活对象本身就超了这个数，GC 拦不住，该 OOM 还是 OOM。
2. 它只管 Go runtime 管的那部分内存。 cgo 里 malloc 的、自己 mmap 的、第三方 C 库占的，都不在统计内。所以要留余量，别贴着容器 limit 设。
3. GOGC=off 要和 GOMEMLIMIT 一起用，单独用等于关掉 GC。 两者一起用时，行为变成"平时不管，快撞上限了才收"，吞吐最好，但对存活量估算要有把握。

至于"GC 拼命跑也压不下来"的死亡螺旋，runtime 内置了保护：gcCPULimiter 用漏桶限制 GC 的 CPU 占用不超过 50%，保证业务线程总还有一半算力能往前走。

8.3 治本：从源头少造垃圾

调参数是治标。真正有效的是让对象根本不进堆。

先看逃逸分析怎么判的

go build -gcflags="-m -l" ./...

真实输出：

./escape.go:12:9:  &User{...} escapes to heap        ← 返回指针，只能上堆
./escape.go:23:9:  u escapes to heap                 ← 塞进 interface{}，上堆
./escape.go:28:13: make([]int, 0, 16) does not escape ← 局部使用、容量是常量，留在栈上

三条常见的逃逸原因：返回局部变量的指针、赋值给 interface{} / any（包括 fmt.Println 的参数）、容量不确定的 slice/map。

几种写法的实测差距

go test -bench . -benchmem

（跑这类基准有个前提：结果必须写进包级变量，否则编译器会发现你没用它，把整段分配优化掉。我第一版就踩了这个坑，make([]byte, 32KB) 跑出 0.22 ns/op，数字完全没意义。）

对应的四条建议：

1. 容量已知就预分配：make([]T, 0, n)、make(map[K]V, n)。
2. 字符串拼接用 strings.Builder，别用 +=。
3. 大对象、高频复用的缓冲区上 sync.Pool。
4. 传大结构体用指针，小结构体传值——传值会拷贝，但拷贝在栈上；传指针不拷贝，但很可能导致逃逸。没有普适答案，用 benchmark 量。

sync.Pool 的三个注意事项

• 池里的对象每轮 GC 都会被清理（Go 1.13 之后引入了 victim cache，能多活一轮）。所以它适合抗高频瞬时复用，不适合当长期缓存。
• 只放同一类、同一量级的对象。往同一个池里塞 1KB 和 10MB 的缓冲，会导致内存占用被大对象拉高。
• Put 回去之前一定要重置内容（buf = buf[:0]），否则下一个使用者会读到脏数据。这类 bug 在并发下极难复现。

8.4 内存只涨不降，怎么查

按这个顺序排查，从最常见的开始：

第 1 步：确认是不是真泄漏。 看 gctrace 里 A->B->C 的第三个数（存活量）。它持续单调上涨才是泄漏；如果只是 RSS 高但存活量平稳，那是内存没还给 OS 的问题（见 9.1）。

第 2 步：查 goroutine 泄漏。 这是 Go 里最高频的泄漏原因，而且往往比对象泄漏更致命——每个 goroutine 起步就是 2KB 栈（runtime/stack.go 里 stackMin = 2048，实际会随调用深度增长），更要命的是它会一直拖着自己引用的所有对象不放。

curl http://127.0.0.1:6060/debug/pprof/goroutine?debug=1 | head -40

看总数是否随时间单调上涨。常见成因：channel 写入但没人读、没有超时的下游调用、time.Ticker 忘了 Stop()、context 没有取消路径。

这也是团队铁律 5（goroutine 必须带 context/errgroup）和铁律 13（所有外部 IO 必须带超时）真正要防的东西：一个没有超时的 HTTP 调用挂住，对应的 goroutine 就永远不退出，它引用的 request、response、buffer 也永远回收不掉。

第 3 步：inuse_space 找持有者。

go tool pprof -http=:8080 -inuse_space http://127.0.0.1:6060/debug/pprof/heap

重点怀疑对象：

• 只增不删的全局 map / slice 缓存——最常见，写的时候觉得"数据量不大"，上线三个月后就不是了。
• 子切片持有大数组：small := big[:10] 之后 big 那几 MB 的底层数组一个字节都释放不掉。要断开就得拷贝：small := append([]byte(nil), big[:10]...)。
• sync.Pool 里塞了超大对象，池不清理就一直占着。
• runtime.SetFinalizer 挂了 finalizer 的对象，回收要多等一轮，形成环还会永远泄漏。

第 4 步：两个时间点做 diff。 比看单个快照有效得多：

curl -s http://127.0.0.1:6060/debug/pprof/heap > t1.pprof
sleep 300
curl -s http://127.0.0.1:6060/debug/pprof/heap > t2.pprof
go tool pprof -http=:8080 -base t1.pprof t2.pprof

-base 会把两份快照相减，涨出来的那部分直接就指向了泄漏点。

9. 几个常被问到的问题

9.1 GC 都跑完了，为什么 top 里内存没降

分三层看：

1. 对象被回收 ≠ 内存还给 OS。 回收只是把格子在 span 里标成空闲，等着复用。
2. 还给 OS 是另一个后台任务干的。 runtime 有个 scavenger，会把长时间没用的页归还给操作系统，节奏比较保守。
3. 归还方式影响 RSS 数字。 Linux 上 Go 默认用 MADV_DONTNEED（源码 runtime1.go 里 if GOOS == "linux" { debug.madvdontneed = 1 }），RSS 会比较及时地降下来；用 MADV_FREE 的话内核只在有压力时才真正回收，top 里看着不降，但其实是可回收的。

要立刻还，可以调 debug.FreeOSMemory()——但它会强制触发一轮 GC 并阻塞。除了"进程刚做完一次性大批量任务、后面要长期空闲"这种场景，不要在正常请求路径上调它。

9.2 要不要手动调 runtime.GC()

生产代码里基本不要。你手动调的时机，几乎不可能比 pacer 根据实时分配速率算出来的更好，而且它会阻塞。

少数合理场景：基准测试里为了让每轮起点一致；进程启动加载完大批初始化数据后清一次；某个明确的批处理任务结束时。

9.3 GC 会移动我的对象吗

堆上的对象不会。 所以对象地址在其生命周期内是稳定的，这也是 cgo 能相对安全地把 Go 指针传出去的前提之一（但仍然受 cgo 指针传递规则约束，别当免死金牌）。

但 goroutine 栈会移动。 栈扩容时整个栈会被拷到新位置，栈上变量的地址随之改变。所以不要试图长期保存一个指向栈变量的裸地址——不过正常写 Go 也做不到这件事，一旦你取了地址并让它外泄，逃逸分析就会把那个变量挪到堆上。

9.4 那分代 GC 呢，Go 为什么不做

因为逃逸分析已经吃掉了分代的大部分收益。分代 GC 赌的是"大部分对象朝生夕死"，而在 Go 里，这批朝生夕死的对象很多压根就没进堆——它们在栈上，函数返回就没了，GC 全程不知道它们存在过。

再加上非分代实现简单得多、也不需要维护 remembered set（跨代引用表），Go 团队选择把复杂度预算花在了降低 STW 上。

10. 一页速查

概念

命令

GODEBUG=gctrace=1 ./app                       # 每轮 GC 打一行
GOGC=200 ./app                                # 少 GC，多吃内存
GOMEMLIMIT=1800MiB GOGC=200 ./app             # 容器里的推荐组合
go build -gcflags="-m -l" ./...               # 看谁逃逸到堆
go test -bench . -benchmem                    # 看 B/op 和 allocs/op
go tool pprof -inuse_space  <heap.pprof>      # 查泄漏
go tool pprof -alloc_space  <heap.pprof>      # 查谁在制造垃圾
go tool pprof -base t1.pprof t2.pprof         # 两个时间点做 diff

排查顺序

内存涨 → 看 gctrace 存活量是否单调上涨 → 查 goroutine 数 → inuse_space 找持有者 → 两点 diff 定位增量。

参考

• A Guide to the Go Garbage Collector — 官方指南，GOGC / GOMEMLIMIT 部分最权威
• Eliminate rescan（混合写屏障提案） — 含正确性证明
• GC Pacer Redesign — 触发目标公式的来龙去脉
• runtime/metrics 指标全集
• Go 源码：runtime/mgc.go（主流程）、runtime/mbarrier.go（写屏障）、runtime/mgcpacer.go（pacer）、runtime/mgclimit.go（CPU 限制器）