一次真实压测把 GOGC 和 GOMEMLIMIT 讲透：GC 参数到底怎么调？
从 Gateway 的 P99 500ms 说起
压测环境：一个 API Gateway，内存分配没细看。压测一上来，P99 从正常的 20ms 直接飙到 500ms+。GC 日志显示 STW（Stop The World）到了 34ms，GC 占 CPU 12%，大概 23 秒触发一次。这数据刚出来时，第一反应是"加内存、调 GOGC"。
但先别急。调参数之前，得想清楚 GC 的压力到底从哪来。
先搞明白 Go 的 GC 到底在看什么
Go 的内存分配器是受 TCMalloc 启发的三级结构：
- 每个 P（逻辑处理器）有独立 mcache 缓存小对象，约 99% 的分配在无锁状态下完成
- 多个 mcache 共享 mcentral（有锁保护）
- 底层 mheap 管理整个堆
对象分三类：微对象（<16B）合并存进 tiny 块；小对象（16B~32KB）走 mcache → mcentral → mheap 的路径；大对象（>32KB）直接走 mheap，全局锁。
GC 本身在 Go 1.22+ 是并发三色标记+清除，配合混合写屏障。STW 的演进：1.0 时代几 ms 到几秒，1.5 约 10ms，1.8+ 小于 1ms，1.22+ 已经小于 200μs。理论上 STW 不该是瓶颈，如果出现 3~4ms 的 STW，说明并发标记阶段严重跟不上分配速度，辅助标记（mark assist）把整个 CPU 拖垮了。
GOGC 的触发公式，以及改它的真实影响
GOGC 的触发阈值：
触发阈值 = GOGC/100 × 上次 GC 后堆大小
- GOGC=100（默认）：堆翻倍触发
- GOGC=200：堆 3 倍触发，GC 频率降低，峰值内存更高
- GOGC=50：堆 1.5 倍触发，GC 频率升高，省内存
- GOGC=off：禁用自动 GC
关键认知：GOGC 只关心"堆大小增长倍数"，不关心进程总共用了多少内存。这两者的差距，正是容器 OOM 的根源。
回到这个 Gateway：2~3 秒触发一次，说明分配的堆内存增长很快。但 GOGC 本身只是一个"倍数触发"机制，堆增长得快，改大 GOGC 只能把触发点延后，不能减少分配量。改大 GOGC 是"把雪崩往后推"，改小 GOGC 是"频繁小扫除"。前者增加 GC 摊还的 CPU 和暂时性内存峰值，后者稳内存但 CPU 开销上升。
所以在确认分配热点之前动 GOGC，就是盲调。
GOMEMLIMIT 什么时候必须配？容器 OOM 是硬指标
Go 1.19+ 的 GOMEMLIMIT 是软内存上限，堆接近上限时 GC 会更积极地触发，防止 OOM。
容器场景必须配：假设 K8s 里限制 1GiB，不配 GOMEMLIMIT 的情况下，GOGC=100 可能要堆涨到接近 2GiB 才触发 GC，直接被 OOM Kill。这发生在很常见的场景里：GOGC 只看堆增长，而容器 limit 是硬边界，触发阈值和容器 limit 之间没有约束关系。配 GOMEMLIMIT=900MiB，留 100MiB 给操作系统和其他运行时开销，让 GC 在逼近上限前提前动作。
配置组合建议（按场景）：
| 场景 | 推荐配置 | 备注 |
|---|---|---|
| 容器/K8s | GOMEMLIMIT=900MiB + GOGC=100 | 靠内存上限兜底，留 10% 余量给 OS |
| 高吞吐/批处理 | GOGC=300 + GOMEMLIMIT=0 | 延迟不敏感，降低 GC 频率，不吃内存上限 |
| 低延迟/Web | GOGC=50 + GOMEMLIMIT=800MiB | 高频 GC 压低堆峰值；或 GOGC=100 + GOMEMLIMIT=900MiB 靠内存上限驱动 GC |
Go 1.21+ 还提供了 GODEBUG=gcpacer=2 来微调的 pacer 策略，但多数场景默认即可。
读 gctrace=1：分清三段 clock，STW 判定就清楚了
开启追踪：
GODEBUG=gctrace=1
输出示例：
gc 25 @6.058s 0%: 0.018+2.3+0.071 ms clock, ... 8->8->6 MB, 9 MB goal, 8 P
clock 三段是这么分的：
0.018 ms：STW 清扫终止（sweep termination）2.3 ms：并发标记（concurrent mark，此时程序在跑）0.071 ms：STW 标记终止（mark termination）
总 STW = 0.018 + 0.071 = 0.089ms。2.3ms 那段毫秒级耗时是并发标记，程序不是停着的，但占用了 CPU 和辅助标记的调度。如果看到总 STW 超过 1ms，说明并发标记跟不上分配，需要查分配热点，而不是无脑调参数。
原文 Gateway 案例里 STW 3~4ms，那就是分配速率远超收集速率，辅助标记回收不过来，停顿自然被拖长。
用 GODEBUG + pprof 定位分配热点的完整步骤
这个 Gateway 的排查路径是：
- 开启 gctrace=1 看基线：STW 3
4ms，GC CPU 12%，间隔 23s - 抓 pprof heap 找分配热点：
go tool pprof http://localhost:6060/debug/pprof/heap
- 对照 top 数据，热点分配集中在几个库函数上：
encoding/jsonDecode：230MBmapstructure.Decode：180MBbytes.Buffer.Grow：95MBstrings.Builder.Grow：45MB
这几个热点指向同一类问题：用了太多临时对象，并且容量不断扩容，堆分配被放大了。
对应的优化：
- sync.Pool 复用 json.Decoder：JSON 解码每次新建 Decoder，底层 Buffer 反复扩容。复用后分配量直接下降一个量级
- 避免频繁 mapstructure 转换：每请求都在做 struct 反射转换。能提前转成目标类型就别用动态转换
- 预分配 slice 容量：提前
make([]T, 0, n)，避免 append 多次扩容复制，这是 bytes.Buffer 和 strings.Builder 两个热点都能削的原因
优化之后，GC 参数仍配了 GOGC=200 + GOMEMLIMIT=1GB，但此时配置的含意已经完全不同——分配量已经降下来，GOGC=200 只是把触发间隔再拉大，不是作为止血手段。
效果数据：
- STW：4ms → 0.4ms，降低 10 倍
- GC 占用 CPU：12% → 5%
- GC 触发间隔：2
3s → 1516s - P99：500ms → 25ms
回到 P99 500ms 的本质：请求主路径上全是堆分配，GC 频率过高导致 mark assist 反压主 goroutine，反而比 GC 本身更耗延迟。
什么情况下别动 GOGC，别用 GOMEMLIMIT
- 默认 100 在多数场景是够用的。 不少服务压测时 P99 偶发抖动，第一反应调 GOGC，但调完发现是无关变量干扰。从 GC 触发日志看没有明显的高频 GC 和长 STW，就不该动。
- 先查逃逸和对象分配，再决定要不要改参数。 改参数是治标。分配热点在 pprof 里能直接看出来，用逃逸分析也能提前发现问题：
go build -gcflags '-m' -l
这个命令会输出每个变量的分配分析结论（逃逸到堆还是留在栈上）。典型的避开逃逸的做法：能用值传递就不用指针、用 make([]T, 0, n) 预分配、避免 interface{} 参数（泛型替代）、sync.Pool 复用、返回值不要返回指针。但注意：跨包场景、未内联的函数、全局变量、interface 值、闭包捕获，这些编译器通常会保守地判定逃逸，碰到这种先想办法改结构，而不是指望 GC 参数兜底。
GOMEMLIMIT 的适用前提是容器有硬性内存边界。本机跑、没有 OOM 风险、或者内存分配波形可控的服务，配 GOMEMLIMIT 只会增加无意义的 GC 压力，反而不稳定。
常见 GC 问题速查
| 现象 | 对策 |
|---|---|
| GC 频繁 | 短生命周期小对象多，用 sync.Pool + 预分配替代 |
| STW > 5ms | goroutine 数 10 万+，上协程池控制并发量 |
| GC CPU > 10% | 辅助标记（mark assist）过多，降低分配速率后再考虑调 GOGC 或用 GOMEMLIMIT |
| RSS 只涨不降 | Go 不把内存归还给 OS，必要时 debug.FreeOSMemory()，或考虑升级 Go 版本用更积极的 scavenge 行为 |
| 容器 OOM | GOMEMLIMIT 设为容器 limit 的 90%（如 1GiB 容器配 900MiB） |
调 GC 参数的顺序，正确的做法是：先看 pprof 分配热点热在哪，再判断是逃逸、容量没预分配、还是临时对象复用不够，最后才轮到 GOGC 和 GOMEMLIMIT 的数值档位。这个 Gateway 案例里，GOGC=200 只是优化的"锦上添花"，权重最大的其实是 sync.Pool 和预分配。
GC 参数不是调优起点，是收尾动作。