oomkilled 是 linux 内核 oom killer 主动终止容器进程，与 go panic 无关；根本原因是 cgroup 内存超限，导致 pid 1 被强制杀死，日志中断、exit code 137、无 defer 执行。
为什么 OOMKilled 不是 Go 程序自己 panic 的
容器被 OOMKilled，说明 Linux 内核的 OOM killer 主动干掉了进程，和 Go runtime 无关——它甚至没机会执行 defer 或 runtime.SetFinalizer。根本原因不是「Go 内存泄漏」，而是容器 cgroup 内存上限被突破，内核强制终止整个进程（PID 1）。常见现象是：日志戛然而止、kubectl describe pod 显示 State: Terminated, Reason: OOMKilled，且 Exit Code: 137。
- Go 的
runtime.GC不会释放给操作系统的内存（除非触发scavenge，且需满足空闲页连续+超时等条件） - 容器内存限制（如
resources.limits.memory: 512Mi）是硬边界，超了就 kill，不讲情面 -
docker stats或kubectl top pod显示的 RSS 常比 Go 的runtime.MemStats.Alloc高 2–3 倍，因为包含未归还的堆页、栈、mmap 区域、CGO 分配等
runtime/debug.ReadGCStats 和 runtime.ReadMemStats 到底看哪个
要看「实时压力」用 runtime.ReadMemStats，重点盯 HeapSys（OS 已分配给 Go 的总内存）和 HeapIdle（当前空闲但未归还给 OS 的内存）；要看 GC 频率是否异常，用 runtime/debug.ReadGCStats 查 NumGC 和最近几次 PauseNs。
-
HeapSys - HeapIdle≈ 当前真正被 Go 使用的内存（含碎片），持续 > 容器 limit 的 70% 就危险 -
NextGC接近HeapAlloc且NumGC每秒 > 1，说明 GC 在疲于奔命，但可能仍压不住增长 - 避免只看
Alloc：它只是已分配对象的活跃内存，不包含元数据、未扫描的栈、mcache 等
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("HeapSys: %v MiB, HeapIdle: %v MiB, Alloc: %v MiB\n",
m.HeapSys/1024/1024, m.HeapIdle/1024/1024, m.Alloc/1024/1024)如何让 Go 主动归还内存给 OS
Go 1.19+ 默认启用 scavenger，但它有保守策略：只在空闲页连续、且空闲超 5 分钟才尝试归还。生产环境常需要更激进控制。
- 启动时加
GODEBUG=madvdontneed=1：让 scavenger 用MADV_DONTNEED而非MADV_FREE，归还更及时（Linux 仅支持） - 手动触发：调用
debug.FreeOSMemory()（慎用！它会 STW，且频繁调用反而增加 GC 压力） - 关键路径避免大块临时分配：比如用
sync.Pool复用[]byte，而不是每次make([]byte, 1 - 检查 CGO：启用
CGO_ENABLED=0编译可排除 C malloc 干扰；若必须用，确保 C 侧也做内存池或及时free
调试时别只盯着 Go，先看容器和内核层面
很多「Go 内存问题」其实是容器配置或外部依赖导致的假象。优先确认三件事：
立即学习“go语言免费学习笔记（深入）”；
- 容器实际限制：运行
cat /sys/fs/cgroup/memory/memory.limit_in_bytes，确认是不是你 YAML 里写的值（有时limit没生效，或被 namespace 默认值覆盖） - 是否存在隐式内存占用：如
net/http的MaxIdleConnsPerHost设太高，连接池堆积大量未复用的 TLS 连接内存；或database/sql的SetMaxOpenConns过大，驱动缓存太多连接 - 检查
/sys/fs/cgroup/memory/memory.usage_in_bytes和memory.failcnt：后者非零说明已多次触发 OOM killer，不是偶发
真要深挖，用 pprof 抓 heap profile 时，务必加 ?debug=1 参数（如 curl "http://localhost:6060/debug/pprof/heap?debug=1"），否则默认只返回摘要，看不到具体分配栈。
