GOGC调太低会加剧GC抖动，因其缩短GC周期导致STW更频繁，叠加高频请求使延迟锯齿化；默认GOGC=100比设为50时GC次数减半，实测调回120后Redis写毛刺降70%以上。
为什么GOGC调得太低反而加剧抖动
很多同学一看到内存涨得快，就立刻把GOGC=50甚至GOGC=20，结果发现GC更频繁、STW毛刺更多——这不是GC变强了，是它被逼着“小步快跑”，每次停顿虽短，但密度高，叠加在高频请求上，接口延迟直接锯齿化。Go 1.8的三色标记GC对堆大小敏感，当GOGC过低，GC周期缩短，但标记和清扫阶段仍需时间，尤其在对象存活率高的场景（比如常驻cache未淘汰），反而让CPU调度更紧张。
- 默认
GOGC=100意味着堆从100MB涨到200MB才触发GC；设为50则涨到150MB就触发，GC次数翻倍，但每次回收的“净收益”未必线性增长 - 实测中，将
GOGC从50调回120后，100ms+ Redis写毛刺下降超70%，因为GC从每300ms一次拉长到每600ms左右一次，调度压力显著缓解 - 别只看内存峰值：用
runtime.ReadMemStats定期打点，重点关注NextGC和LastGC时间差，以及PauseNs分布，比单纯盯Alloc更有诊断价值
sync.Pool复用对象时最容易漏掉的三件事
sync.Pool不是开箱即用的银弹，用错反而引入数据污染或逃逸。我们在线上曾因一个未Reset()的bytes.Buffer池，导致后续请求读到前序请求残留的二进制数据，引发Redis协议解析错误。
- Pool的
New函数必须返回**已初始化、可直接使用**的对象，例如&bytes.Buffer{}，而不是bytes.Buffer{}（后者会逃逸到堆，且Get后无法保证字段清空） - 每次
Get()后必须显式清理状态：buf.Reset()、slice = slice[:0]、结构体字段重置，不能依赖“刚从New创建”的假定 - Pool对象不跨goroutine安全复用：如果某个buffer在HTTP handler里Put进池子，又被另一个定时任务goroutine Get走，中间没做同步，极易出竞态——建议按用途分池，比如
redisCmdPool和httpRespPool分开
逃逸分析没跑对，预分配就白做了
很多人写了make([]byte, 0, 4096)还觉得稳了，结果pprof显示alloc_objects里这个切片仍在高频上堆——根本原因是编译器判定它“逃逸”了。常见诱因包括：作为函数返回值传出、被闭包捕获、赋值给接口类型变量、或传入了反射/日志等泛型函数。
- 用
go build -gcflags="-m -m"检查关键路径，重点找escapes to heap和moved to heap字样，不是所有make都能留在栈上 - 避免在热路径里把切片传给
fmt.Sprintf或log.Printf，它们接收...interface{}，强制逃逸；改用fmt.Fprintf配bytes.Buffer池，或直接strconv系列 - 结构体字段顺序影响逃逸：如果一个大数组字段（如
[1024]byte）放在结构体末尾，前面的小字段可能因对齐被迫一起上堆；把大字段前置能提升栈分配成功率
GC抖动和CPU调度抖动经常被混为一谈
监控里看到CPU使用率毛刺和延迟毛刺时间吻合，第一反应是“CPU不够”，但真实情况往往是GC STW期间协程被强制挂起，调度器误判为“该让出CPU”，导致其他goroutine排队等待，放大延迟。我们在排查时发现，go tool trace里STW事件和Scheduler latency尖峰完全重叠，而top显示的CPU利用率其实没超70%。
立即学习“go语言免费学习笔记（深入）”；
- 开启
net/http/pprof后，访问/debug/pprof/trace?seconds=30，导入到浏览器查看，重点观察GC pause是否与Redis耗时毛刺对齐 - 用
GODEBUG=schedtrace=1000打印调度器状态，如果看到大量procs: 8 idle: 0 run: 8持续出现，说明GOMAXPROCS设置合理但GC正在抢占，不是CPU真瓶颈 - Go 1.8不支持
GOMEMLIMIT，但可用runtime/debug.SetMemoryLimit（需patch）或升级到1.19+，配合GOGC形成双控，比单调GOGC更稳定
