Go 内存为什么不能都怪 GC：goroutine 泄漏、无界缓存和高分配速率修法完全不同

Thu, 28 May 2026 14:20:00 +0800

服务又 OOM 了。

Pod 刚重启，群里已经开始出方案：GOMEMLIMIT 设低一点，GOGC 调一下，limit 先加 1Gi，GC 日志再翻一遍。

这些动作有时候能救火，但经常救不到根上。

因为很多 Go 服务所谓的“内存泄漏”，根本不是一种病。goroutine 卡住、全局 map 只增不删、热路径疯狂分配，看起来都像内存曲线往上走，修法却完全不同。

你把它们都叫 GC 问题，排查就会变成调参赌博。

GC 不是清洁工，它不能删除还被引用的对象。

这篇不再重复讲 OOMKilled 第一现场怎么确认。上篇已经讲过：先看谁被杀、撞到什么 limit、heap 和 RSS 是不是同一本账。这篇往下走一步：当你确认 Go 服务确实有内存压力，怎么把“泄漏”拆成三类。

拆清楚以后，很多争论会少一半。

第一类：goroutine 泄漏，真正漏的是生命周期

goroutine 泄漏最容易被低估。

很多人听到 goroutine，会觉得它很轻：几 KB 栈，问题不大。但线上事故里，麻烦通常不只是 goroutine 自己占多少内存，而是它还挂着什么。

请求已经超时了，调用方走了，下游 channel 还在等发送；context 已经 cancel 了，后台 worker 还在跑；连接断了，读循环没有退出；定时任务里起了 goroutine，却没有任何关闭协议。

这些 goroutine 还活着，栈上可能就挂着 request、response、session、buffer、logger field、trace span。

对象还被引用着，GC 就不会删。

排查信号通常很直接：

1
2
3
4


goroutine 数持续上涨，业务回落后不回落；
goroutine profile 里同一类栈越来越多；
heap diff 里能看到被这些 goroutine 间接持有的对象；
GC CPU 跟着变高，但 live heap 不一定夸张到一眼能看出来。

事故现场不要只抓 heap。goroutine profile 要一起留：