oom killer所致，因dmesg显示killed process、k8s中pod状态为oomkilled且exit code 137、服务日志戛然而止无panic痕迹；ps rss远超runtime.memstats.alloc因包含mmap/cgo等堆外内存；gomemlimit仅调控gc时机，不限制堆外分配。
怎么确认是OOM Killer干的，不是Go自己panic了
进程突然消失、日志戛然而止、没任何panic堆栈，这三点加起来基本就能锁定是内核动的手。必须交叉验证三处线索：dmesg -T | grep -i "killed process"里有明确PID和total-vm/anon-rss数值；Kubernetes中kubectl describe pod显示Reason: OOMKilled且Exit Code: 137；服务日志最后一行不是panic也不是defer执行痕迹，systemd或nohup日志也同步中断。
为什么ps看到的RSS远大于runtime.MemStats.Alloc
runtime.ReadMemStats只管Go堆里那块内存，而ps -o rss统计的是整个进程映射的所有物理页——包括mmap分配的共享内存、CGO调用C库时malloc的缓冲区、net/http连接池里滞留的tls.Conn底层socket buffer、甚至长期存活goroutine锁住的未用栈空间。差值超过500MB就得警觉：
-
MemStats.Sys - MemStats.HeapSys持续大于500MB → 堆外内存失控 -
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap?debug=1→ View → Proto → 搜extra_memory_usage（Go 1.21+） - 用
cat /proc/$PID/smaps | awk '/^Size:/ {sum+=$2} END {print sum}'看总映射量，再比对RSS
GOMEMLIMIT和GOGC到底管不管用
GOMEMLIMIT只是软水位线，它只影响GC触发时机，不拦mmap、不拦CGO、不拦连接池缓存。设GOMEMLIMIT=1.5g，但cgo开了1GB共享内存，RSS照样飙到2.5GB被杀。而GOGC=10这种低值反而容易恶化问题：GC太频繁，元数据开销大，停顿多，对象存活率高时还可能推高堆外压力。
真正该做的是分层设限：
- 容器场景：
docker run --memory=2g或 K8sresources.limits.memory: 2Gi，再配GOMEMLIMIT=1.5g（建议为limit的75%） - 裸机部署：
systemd里用MemoryMax=2G+MemoryLow=1.6G，比ulimit -v可靠得多（后者对mmap无效） - 禁用
GOGC硬调，改用runtime/debug.SetGCPercent(-1)临时关闭GC来定位是否真由GC延迟引发
cgo和mmap是OOM Killer最爱盯的两类堆外内存
很多Go服务OOM，根子不在Go代码，而在C侧或系统调用。比如OpenSSL握手缓存、SQLite page cache、syscall.Mmap映射大文件、unsafe.Alloc申请大块内存，这些全绕过Go GC。
排查和收敛要点：
- 临时编译关CGO：
CGO_ENABLED=0 go build，如果RSS骤降，说明cgo是主因 - 检查所有
C.malloc调用点，确保对应C.free；用valgrind --tool=memcheck跑小规模测试（需Linux环境） - 避免
os.CreateTemp写入超大文件后不Close或Unlink，临时文件句柄残留会锁住mmap页 - HTTP客户端务必设限：
http.DefaultTransport.MaxIdleConns=100，MaxIdleConnsPerHost=100，IdleConnTimeout=30s
最易被忽略的一点：GOMEMLIMIT只对Go堆起作用，而OOM Killer杀进程看的是RSS。哪怕你把GC调得再激进，只要cgo或mmap在后台悄悄吃掉1.5GB物理内存，进程就还是会被标记为“最肥的那只羊”。
