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；runtime.ReadMemStats里Alloc才200MB，ps -o rss却显示1.8GB，说明堆外内存失控——这问题不查mmap、CGO、连接池和goroutine栈，光调GOGC或GOMEMLIMIT没用。
怎么确认是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日志也同步中断
只要满足这三点，就是内核动的手，runtime.GC连跑都没机会跑完。
为什么ps看到的RSS远大于runtime.MemStats.Alloc
RSS包含所有被进程映射但未归还的物理内存页，而runtime.MemStats只统计Go堆管理的部分。差值大，说明有“堆外内存”在吃资源：
-
mmap分配的大块内存（如unsafe.Map、syscall.Mmap、os.CreateTemp写大文件） -
CGO调用C库分配的内存（如OpenSSL握手缓存、SQLite page 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：
- 容器场景：用
docker run --memory=2g或K8s的resources.limits.memory设硬限，再配GOMEMLIMIT=1.5g（建议设为limit的75%）让GC提前介入 - 裸机部署：用
systemd的MemoryMax+MemoryLow，比ulimit -v更可靠（后者对mmap无效） - 别信
GOGC=10能救命——它只会让GC更频繁，但若对象存活率高，反而加剧停顿和元数据开销 - 示例：
GOMEMLIMIT=1600MiB ./myserver会让GC在堆内存接近1.6GB时启动，但若cgo开了1GB的共享内存，RSS照样爆到2.6GB被OOM Killer干掉
真正要盯的是三类易失控对象：短期大对象（>32KB直接进堆）、未释放的mmap区域、以及CGO侧漏掉的free——这些地方出问题，GOMEMLIMIT连提醒都来不及发。
