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 要一起留：

OOMKilled 到底是谁动的手：Go 为什么要先看 kubectl describe 再做 pprof diff

Thu, 28 May 2026 10:37:00 +0800

服务又被 OOMKilled 了。

Pod 刚重启，群里已经开始报菜名：把 GOGC 调低一点，给 GOMEMLIMIT 设个值，容器 limit 再加 1Gi，顺手翻一下 GC 日志。

这些动作不一定错，但顺序错了。

你现在看到的是“尸体”，不是“凶手”。OOMKilled 只说明容器被内核杀掉了，不说明是谁把内存账花爆了。可能是 Go heap 真的在涨，可能是 goroutine 泄漏把对象挂住了，可能是 RSS 里有 cgo、mmap、tmpfs，也可能只是容器 limit 给得太紧。

很多 Go 内存事故，第一步不是调 GC，而是先把账本拿出来。

OOMKilled 是结果，不是根因。先查谁杀了你，再谈怎么救。

第一步：先确认谁杀了你

线上内存告警一来，最危险的动作不是慢，而是快。

你一快，就会把“容器被杀”理解成“Go heap 有问题”；把“GC CPU 变高”理解成“GC 参数不合适”；把“RSS 比 heap 大”理解成“Go 没把内存还给系统”。

这些判断都太早。

先看 Kubernetes 给你的第一现场：

1
2
3
4
5


kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl top pod <pod> -n <ns> --containers
kubectl get pod <pod> -n <ns> \
 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

你要先回答几件事：

性能排查 on Zampo Blog

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

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

OOMKilled 到底是谁动的手：Go 为什么要先看 kubectl describe 再做 pprof diff

第一步：先确认谁杀了你