Go进程被OOM Killer终止是因RSS超cgroup限制致内核强制杀PID 1，非Go panic；确认需三处线索：dmesg显示killed process、K8s中Reason: OOMKilled且Exit Code 137、日志戛然而止无defer执行；RSS远超MemStats.Alloc说明存在mmap/CGO/连接池等堆外内存占用。
go常驻进程被linux oom killer终止，不是程序panic，而是rss（常驻集）超cgroup限制后内核强制杀掉pid 1。关键不在堆内存是否泄漏，而在rss是否失控——runtime.readmemstats里的alloc可能才200mb，ps -o rss却已飙到1.8gb。
怎么确认是OOM Killer干的，不是Go自己崩了
看三处线索，缺一不可：
-
dmesg -T | grep -i "killed process"输出里有明确时间、PID、进程名和total-vm/anon-rss数值 - Kubernetes中
kubectl describe pod显示State.Terminated.Reason: OOMKilled且Exit Code: 137 - 容器日志戛然而止，无
panic、无defer执行痕迹，systemd或nohup日志也同步中断
只要满足这三点，就是内核动的手，Go runtime连GC都没机会跑完。
为什么ps看到的RSS远大于runtime.MemStats.Alloc
RSS包含所有被进程映射但未归还的物理内存页，而runtime.MemStats只统计Go堆管理的部分。差值大，说明有“堆外内存”在吃资源：
-
mmap分配的大块内存（如unsafe.Map、syscall.Mmap、os.CreateTemp写大文件） - CGO调用C库分配的内存（如
OpenSSL握手缓存、SQLitepage cache），C.free漏掉就等于RSS持续涨 - net/http连接池堆积：默认
DefaultTransport不限制MaxIdleConns，大量短HTTPS请求会滞留tls.Conn和socket缓冲区 - goroutine栈未回收：长期存活的goroutine（比如漏掉
context.CancelFunc）会锁住整个栈内存，哪怕栈里没数据
查证方法：go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap?debug=1 → View → Proto → 搜extra_memory_usage（Go 1.21+），或算MemStats.Sys - MemStats.HeapSys，超500MB就得重点盯。
GOMEMLIMIT设多少才有效，GOGC要不要调
GOMEMLIMIT是面向RSS的软水位线，不是硬闸门；它只影响GC触发时机，不阻止mmap或CGO涨RSS：
- 设为容器
memory.limit_in_bytes的70%–80%，例如limit=2Gi →GOMEMLIMIT=1610612736（1.5Gi） - 别同时设极低
GOGC（如GOGC=10），它会让GC更频但可能加剧STW，且对非堆内存完全无效 -
GOGC保持默认100即可，真要调，优先观察MemStats.NumGC是否每秒>1且NextGC逼近HeapAlloc——那是GC在疲于奔命，不是调参数能救的
真正要做的，是配合GOMEMLIMIT做减法：关掉不用的http.Transport连接复用、显式调SetMaxOpenConns、避免context.WithTimeout漏cancel()（参考etcd watch死循环案例）、CGO必须配C.free。
如何让Go更快把空闲内存还给OS
Go 1.19+默认启用scavenger，但它很保守：只归还连续空闲超5分钟的页。生产环境常需更激进策略：
- 启动时加
GODEBUG=madvdontneed=1，让scavenger用MADV_DONTNEED而非MADV_FREE，归还更及时（仅Linux有效） - 慎用
debug.FreeOSMemory()：它会STW，频繁调反而拖慢吞吐；只在极低峰期手动触发一次 - 别依赖
sync.Pool自动清理：Put进去的对象若含指针或未清零，Pool可能长期持有底层数组；Get后记得cap检查或显式make新切片
最易被忽略的一点：容器场景下，GOMEMLIMIT再准也没用，如果cgroup v2的/sys/fs/cgroup/memory.max没设对，或者v1的memory.limit_in_bytes被父cgroup覆盖——得先确认cat /proc/1/status | grep -i memory里的限制值是否符合预期。
