Go程序在容器中runtime.ReadMemStats内存远低于cgroup/memory.max，因Go运行时默认不主动归还内存页，而是复用空闲堆内存；GOMEMLIMIT仅限堆内存，不包含栈、CGO等非堆内存，需预留100–150MiB余量并审计全链路内存。
Go 程序在容器里 runtime.ReadMemStats 显示的内存远低于 cgroup/memory.max
这不是 Go 的 bug，是 Go 运行时默认不主动向操作系统归还内存页导致的。它会把已分配但空闲的堆内存保留在自己的内存池（mheap）里，反复复用，避免频繁系统调用。所以 runtime.ReadMemStats 中的 Sys 字段可能接近容器内存上限，但 Alloc 和 HeapInuse 却很低——系统看到的是 Go 占着不放，而 Go 自己觉得“我用得不多”。
- 典型现象：
docker stats或cgroup/memory.current显示 900MB，runtime.ReadMemStats却只报告Alloc=120MB、HeapInuse=200MB - 根本原因：Go 1.19+ 默认启用
scavenger，但它只在内存压力明显时才触发；容器 cgroup 的限制不会自动触发 scavenger 加速回收 - 临时缓解：启动时加
GODEBUG=madvdontneed=1，让 scavenger 使用MADV_DONTNEED（Linux）而非默认的MADV_FREE，释放后立刻被 cgroup 计入可用 - 注意：
MADV_DONTNEED在某些内核版本（如 CentOS 7 的 3.10）上行为不一致，可能导致延迟升高，建议在目标环境实测
设置 GOMEMLIMIT 后，Go 还是 OOM 被 cgroup kill
GOMEMLIMIT 是 Go 1.19 引入的硬性堆目标上限，但它控制的是 Go 堆（GC heap），不包括栈、全局变量、CGO 分配、OS 线程栈、profiling buffer 等。cgroup 的 memory.max 是进程整体 RSS 上限，两者不在同一层。
- 常见误判：设了
GOMEMLIMIT=512MiB，但容器memory.max=600MiB，结果仍被 kill——因为 Go 堆外内存（比如大量net.Conn的读缓冲区、CGO 调用 malloc 的内存）超了 600MiB - 验证方法：在容器中运行
cat /sys/fs/cgroup/memory.current对比runtime.ReadMemStats().Sys，差值大概率就是非堆内存 - 关键参数组合：
GOMEMLIMIT应比memory.max小至少 100–150MiB，留出非堆开销余量；同时建议配GOGC=30（更激进 GC）辅助控堆 - 若用了
net/http且并发高，检查http.Server.ReadBufferSize是否过大（默认 4KiB/连接，万级连接就吃掉 40MiB+）
为什么 debug.SetMemoryLimit 不生效或报错 invalid memory limit
debug.SetMemoryLimit 是运行时 API，但它只能在 GOMEMLIMIT 未设置（即为 0）时调用才有效；一旦启动时设了环境变量，运行时就锁定该值，后续调用直接 panic。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
GOMEMLIMIT=512MiB ./myapp再在代码里调debug.SetMemoryLimit(256 → 触发 <code>panic: invalid memory limit - 正确路径：要么全用环境变量控制（推荐），要么完全不用
GOMEMLIMIT，改用代码初始化时调debug.SetMemoryLimit（需确保首次 GC 前执行） - 注意：该函数不是线程安全的，不能在 GC 运行中或并发 goroutine 里多次调用
- 调试技巧：启动后立刻打印
debug.ReadBuildInfo().Settings中的GOMEMLIMIT值，确认是否被环境变量覆盖
容器内 Go 程序 RSS 持续上涨但 GC 没触发
GC 只管堆对象，RSS 上涨却没触发 GC，说明增长来自非 GC 管理区域：CGO 分配、unsafe 手动内存、sync.Pool 持有大对象未释放、或 runtime.MemStats 中 StackSys/MSpanSys 异常升高。
立即学习“go语言免费学习笔记（深入）”；
- 快速定位：用
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap查看分配源头，重点过滤C.malloc、runtime.stackalloc、sync.(*Pool).pinSlow - 常见坑：
sync.Pool存了大字节切片（如[]byte），但应用逻辑没及时Put回去，Pool 会一直持有直到下次 GC sweep，而 sweep 不清 Pool 缓存 - 规避方式：对大对象 Pool 设置 size 限制，或改用带 TTL 的缓存（如
lru.Cache）；CGO 场景强制用C.free并加runtime.SetFinalizer做兜底 - 终极验证：在容器里执行
cat /proc/self/status | grep ^VmRSS，再对比runtime.ReadMemStats()各字段总和，差值 >20% 就基本确定是非堆泄漏
真正难的不是调参，是区分“Go 堆”和“进程 RSS”这两个层面——前者能靠 GC 和 GOMEMLIMIT 管，后者得靠 cgroup 配额 + 全链路内存审计。漏掉 CGO 或 net.Conn 缓冲区，再细的 GC 参数也没用。
