内存一直涨，不一定是泄漏：Go GC 真正在做什么

Thu, 21 May 2026 20:25:00 +0800

服务内存从 800MB 慢慢涨到 2.6GB。

曲线不陡，不像雪崩。它只是每天往上爬一点，重启以后掉下来，过几天又回到老地方。告警响了，群里第一句话通常是：是不是内存泄漏？

这个判断不算错，但太急。

在 Go 服务里，内存持续上涨可能是真泄漏，也可能是 live heap 变大了，可能是 GOGC 目标让下一轮回收来得更晚，也可能是短命对象太多，把 GC 拖进了频繁工作。还有一种更容易误判：heap 已经回收了，但 RSS 没有马上按你想象的方式降下来。

内存涨，不等于内存泄漏。

要把这件事查清楚，不能只盯 RSS。你得知道 Go GC 什么时候启动、怎么判断对象还活着、为什么需要写屏障、哪里会停顿，以及哪些参数是真的能调。

GC 不是保洁员，是成本调度器

很多人对 GC 的直觉是“内存不用了，运行时帮我扫掉”。这个说法只对了一半。

真正重要的是另一半：GC 每扫一次，都要花 CPU；扫得太勤，CPU 被回收器吃掉，服务吞吐和延迟会受影响。扫得太晚，内存峰值又会涨上去，容器可能先把你杀掉。

所以 Go GC 不是等地上脏了才来的保洁员。它更像一个拿着预算表的人：上一轮还有多少对象活着？再往后拖一点，内存能不能接受？现在开始扫，CPU 能不能接受？

Go 官方 GC Guide 讲得很清楚：GC 主要消耗 CPU 和物理内存。想省 CPU，就得允许堆多长一会儿；想省内存，就得让 GC 更频繁地工作。

这就是 GOGC 的本质。

GOGC=100 不是“内存达到 100MB 触发 GC”。它的意思更接近：在上一轮存活堆的基础上，允许新分配对象按约 100% 的比例增长，再触发下一轮 GC。Go 1.19 之后，目标堆计算还会把 GC roots 的成本纳入进来，可以简化理解为：

1

下一轮目标 ≈ live heap + (live heap + GC roots) × GOGC / 100

GOGC 调的是成本，不是情绪。