《Go 语言高级编程》6.2 GC 调优与 GOGC/GOMEMLIMIT

6.2 GC 调优与 GOGC/GOMEMLIMIT

Go 的 GC 被设计成「不用你管」——默认参数能覆盖绝大多数场景。但「不用管」不等于「不能管」：当服务的内存曲线在容器里顶到 limit 被杀、或者尾延迟被 GC 尖刺拉高时，你会需要两个旋钮：GOGC 与 GOMEMLIMIT。

本节要回答：GOGC 与 GOMEMLIMIT 各自控制什么、拧动它们换来什么、付出什么。结论是：GOGC 是「用 CPU 换内存」，GOMEMLIMIT 是「用 CPU 与时间换内存上限」；本机实测把 GOGC 从默认 100 调到 400，GC 次数从 63 降到 16、GC CPU 占比从 5.60% 降到 1.28%，代价是运行结束时的 HeapAlloc 从 123 MiB 涨到 229 MiB；这些是原稿单次记录，不能当成峰值或本轮复测结果。

6.2.1 GC 的基本模型：目标堆与实际触发阈值

Go 的 GC 是并发标记-清扫。它不靠「定时」触发，而靠堆增长比例触发：近似目标堆为“存活堆 + (存活堆 + GC roots) × GOGC/100”，GC roots 包括可扫描的栈与全局变量；实际启动阈值由 pacer 估算，通常在目标之前开始标记，以便在堆增长期间完成工作。

默认 GOGC=100，在忽略 GC roots、最小堆目标与软内存限制时，可近似为存活堆的两倍。这是简化模型，不保证 HeapAlloc 固定在这个值。参见 官方 GC 指南 。

两个旋钮的定位因此很清楚：

6.2.2 GOGC：用 CPU 换内存

写一段分配密集的程序（每次 64 KiB，循环 20000 次，保留 1/16），在不同 GOGC 下各跑一遍，程序内用 runtime.ReadMemStats 采集：

func churn(n int) {
	var keep [][]byte
	for i := 0; i < n; i++ {
		b := make([]byte, 1<<16) // 64 KiB
		b[0] = byte(i)
		if i%16 == 0 {
			keep = append(keep, b)
		}
	}
	runtime.KeepAlive(keep)
}

原稿记录（Apple M1 Pro，GOTOOLCHAIN=go1.27.0，单次运行；本轮尚未按原负载复测）：

=== 默认 ===
heap_alloc=123MiB total_alloc=1250MiB num_gc=63 gc_cpu_frac=0.0560 wall=105ms
=== GOGC=off ===
heap_alloc=1250MiB total_alloc=1250MiB num_gc=0 gc_cpu_frac=0.0000 wall=38ms
=== GOGC=20 ===
heap_alloc=88MiB total_alloc=1250MiB num_gc=270 gc_cpu_frac=0.0903 wall=73ms
=== GOGC=400 ===
heap_alloc=229MiB total_alloc=1250MiB num_gc=16 gc_cpu_frac=0.0128 wall=43ms
=== GOMEMLIMIT=64MiB ===
heap_alloc=78MiB total_alloc=1250MiB num_gc=897 gc_cpu_frac=0.0727 wall=368ms

整理成对照表：

读这张表的三个要点：

1. GOGC 越小，GC 越频繁、内存越低、CPU 越高。GOGC=20 本组结束时 HeapAlloc 为 88 MiB，但 GC 次数翻了 4 倍多，CPU 占比从 5.6% 涨到 9%。
2. GOGC 越大，GC 越少、CPU 越低、内存越高。GOGC=400 把 GC 次数砍到 16，CPU 降到 1.28%，代价是本组结束时 HeapAlloc 增大。
3. GOGC=off 关闭按百分比触发的自动 GC；有限的 GOMEMLIMIT 或显式 runtime.GC() 仍可触发回收。本组未配置这些约束，结束时 HeapAlloc 接近累计分配量。是否采用 off，要评估分配总量、寿命和内存限制，不能仅按 CLI 或服务分类。

注意 GOGC=off 的墙钟时间（38 ms）反而最短——省掉了 GC 本身的开销。但这是假象：一旦分配量超过物理内存，off 会直接 OOM。

6.2.3 GOMEMLIMIT：用 CPU 与时间换内存上限

GOMEMLIMIT 是 Go 1.19 引入的软内存上限。它不阻止程序超限，而是在「逼近上限」时提前触发 GC，避免被容器 OOM Killer 干掉。实测把它设成 64 MiB：

heap_alloc=78MiB total_alloc=1250MiB num_gc=897 gc_cpu_frac=0.0727 wall=368ms
env GOGC="" GOMEMLIMIT="64MiB" memlimit=64MiB

897 次 GC、368 ms——比默认多出一个数量级的 GC 次数和 3.5 倍的墙钟时间。这就是「软上限」的代价：它不是免费的保护，而是增加 GC 开销以尽量降低 Go runtime 管理的内存，不保证不超限。

GOMEMLIMIT 与 GOGC 的关系是「谁先触发谁生效」：

最后一行是最重要的边界：如果存活数据本身就超过 GOMEMLIMIT，再多 GC 也没用——因为回收不掉活数据。这种情况下程序可能陷入 GC thrashing。runtime 的 GC CPU 限制器会避免全部时间都用于 GC，但代价是允许越过软限制；是否 OOM 还取决于外部硬限制。设 GOMEMLIMIT 前必须先量清楚活堆的上界。

6.2.4 gctrace：把 GC 行为打印出来

GODEBUG=gctrace=1 每轮 GC 打一行。实测（默认配置）：

$ GOTOOLCHAIN=go1.27.0 GODEBUG=gctrace=1 ./gcprobe
gc 1 @0.001s 2%: 0.029+0.13+0.003 ms clock, 0.29+0.062/0.21/0+0.032 ms cpu, 3->4->0 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 10 P
gc 2 @0.001s 3%: 0.018+0.085+0.015 ms clock, 0.18+0.016/0.066/0+0.15 ms cpu, 3->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 10 P
gc 3 @0.002s 4%: 0.013+0.073+0.013 ms clock, 0.13+0.010/0.057/0.008+0.13 ms cpu, 3->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 10 P

字段逐个拆：

最关键的是 3->4->0 MB：末尾的 0 MB 是存活堆。在 GC roots 可忽略、内存限制未约束且不受最小堆目标影响时，可以比较目标堆与存活堆的比例，辅助判断 GOGC 是否生效——上例里 4 MB / 0 MB 没有意义（存活堆太小），但在真实负载下这个比值会稳定在 1 + GOGC/100 附近。

三阶段的墙钟数字里，中间那段（并发标记）通常最大，虽然业务 goroutine 仍可运行，GC 的 CPU 竞争与 mark assist 也可能影响尾延迟。首尾两段反映 STW，分析请求 P99 还需关联 trace 与请求指标。

6.2.5 为什么 GOMEMLIMIT 是容器时代的必需品

在物理机时代，GOGC 一个旋钮够用：内存不够就加条子。进了容器时代，程序面对的是一个硬性内存上限——超过 limit 就被 OOM Killer 直接杀掉，没有任何商量余地。

GOGC 的致命缺陷正在这里：**它按「比例」触发 GC，完全不知道外部上限。**一个 GOGC=100 的程序，如果活堆是 500 MiB，它会把堆推到 1 GiB 才回收；而容器 limit 可能只有 512 MiB——程序会在 GC 触发之前就被杀。

GOMEMLIMIT 补的就是这个盲区：

// 容器 limit 1GiB 时，把软上限设在 900MiB
debug.SetMemoryLimit(900 << 20)

它的语义是「尽力不越过」：越接近上限，GC 触发得越早、越频繁。它不是硬限制——如果活堆本身超过 limit，程序可能超过软限制；是否发生 OOM 取决于外部硬限制，不能据此保证服务存活。

代价已在 6.2.3 量化：本机把 limit 压到 64 MiB，GC 从 63 次涨到 897 次。不能单凭这组数字认定设置值得：还要检查吞吐、P99、CPU 与 OOM 风险。存活集已超过限制时，应先降低负载或调整内存预算。

6.2.6 Green Tea GC 与调优的关系

Go 1.26 起默认启用了 Green Tea GC（本机 1.26 与 1.27 的 buildcfg/exp.go 基线都含 GreenTeaGC: true，见 4.3.4）。它改的是标记阶段的内存局部性，源码里的核心描述是：

The core idea behind Green Tea is simple: achieve better locality during
mark/scan by delaying scanning so that we can accumulate objects to scan
within the same span, then scan the objects that have accumulated on the
span all together.

做法是维护两套位图（marks 与 scans），把同一 span 内待扫描的对象攒起来批量扫，从而摊薄元数据访问、给预取创造机会。它在 mgcmark_greenteagc.go 里由 //go:build goexperiment.greenteagc 守卫。

对调优者的实际影响：

关键结论：**Green Tea GC 不需要你改任何调优参数。**它换的是「怎么标记」，不是「什么时候标记」。调优决策表里的所有取舍照旧成立——只是同样参数下的 GC CPU 占比可能比旧版本更低。

6.2.7 调优决策表

把上面所有结论收进一张表：

设置方式有两种，效果等价：

// 代码内（可动态调整）
debug.SetGCPercent(400)
debug.SetMemoryLimit(512 << 20)

// 环境变量
// GOGC=400 GOMEMLIMIT=512MiB ./server

容器部署的推荐组合：设 GOMEMLIMIT 为容器 limit 的 80%~90%（主要为 runtime 口径外的 cgo、mmap、二进制映射与容器其他进程留余量；栈、全局变量等 runtime 管理开销已计入软限制），GOGC 保持默认。这样平时按 GOGC 走，逼近上限时自动收紧——仍需验证是否有 OOM 或频繁 GC，不能把起始比例当成保证。

6.2.8 调优闭环：测量 → 调整 → 回归

GOGC 是「百分比」而不是「MB」，这个单位经常被误读。GOGC=100 的含义是「按 100% 计算相对存活堆与 GC roots 的增长预算」，不是「堆上限 100 MB」。所以：

• 一个活堆 10 MiB 的程序，GOGC=100 时目标堆约 20 MiB；
• 同一个程序把活堆涨到 500 MiB，目标堆自动变成约 1 GiB——参数没变，内存曲线却涨了 50 倍。

这正是「先测量」不可跳过的原因。一个可执行的调优闭环：

三个必须记录的指标（对应 6.3 节的 runtime/metrics 名字）：

调优的最后一步永远是「固化 + 留注释」：把 GOGC=400 写进部署配置的人，半年后多半忘了当初为什么是 400。把「为什么」写进注释，比参数本身重要。

一句话收束：GC 调优没有「更好的参数」，只有「更匹配负载的取舍」。GOGC 调的是「CPU 与内存的兑换率」，GOMEMLIMIT 调的是「内存天花板」；两个都设之前，先用 gctrace 把当前的 GC 行为量出来——否则就是在盲调。

阅读导航：上一节：6.1 逃逸分析决策表 · 下一节：6.3 runtime/metrics 与 trace 实战 。