go 1.19+ 默认启用 madv_free 后 rss 不降是正常现象，因内核仅标记内存为“可回收”，缺内存时才归还；它不解决内存泄漏，需结合 pprof 看 heap_released 判断真实释放。
Go 程序在容器里 RSS 居高不下，MADV_FREE 是不是没生效？
不是没生效，是 Go 1.19+ 默认启用 MADV_FREE 后，Linux 内核不会立刻把内存还给系统——它只标记为“可回收”，等系统真正缺内存时才清零并归还。所以 top 或 docker stats 看到的 RSS 不会马上下降，这是正常行为，不是泄漏。
-
MADV_FREE只在 Linux 4.5+ 且启用了CONFIG_TRANSPARENT_HUGEPAGE=m/y的内核上起作用；老内核（如 CentOS 7 默认 3.10）会自动 fallback 到MADV_DONTNEED - Go 运行时只对 span 中“整页空闲”的内存调用
madvise(..., MADV_FREE)，碎片化释放不触发 - 容器 cgroup v1 下，RSS 统计滞后约 1–2 秒；cgroup v2 更准，但需确认
/sys/fs/cgroup/memory.max是否设限
runtime/debug.FreeOSMemory() 在容器里还有用吗？
基本没用。它强制触发一次 GC + 归还空闲 span，但在 MADV_FREE 模式下，只是把内存标记为可回收，RSS 数值不变；而且频繁调用反而干扰运行时的内存调度节奏，可能引发更多小对象分配压力。
- 仅在调试阶段、确认无活跃引用后临时使用，生产环境禁止周期性调用
- 它不解决根本问题：如果程序持续持有大 slice 或 map，GC 不会回收底层数组，
FreeOSMemory也无能为力 - 替代方案更可靠：用
pprof查heap_inuse和heap_released，比看 RSS 更反映真实内存归还情况
如何验证 MADV_FREE 实际是否工作？
别盯 RSS，看内核统计和 Go 运行时指标更直接：
- 检查
/proc/<pid>/smaps</pid>中Madvise字段：有大量非零值说明MADV_FREE已应用 - 运行时开启
GODEBUG=madvdontneed=1强制退回到MADV_DONTNEED，对比 RSS 下降速度（仅用于验证，勿长期开启） - 用
go tool pprof <binary> http://localhost:6060/debug/pprof/heap</binary>，关注heap_released是否随 GC 增长——这才是真正归还给操作系统的字节数
容器内存限制下，MADV_FREE 可能导致 OOM 被杀？
有可能，但原因不是 MADV_FREE 本身，而是 cgroup 内存统计与内核实际回收之间的窗口期。当容器接近 memory.limit_in_bytes 时，内核可能还没来得及回收那些被 MADV_FREE 标记的页，就判定超限并触发 OOM Killer。
立即学习“go语言免费学习笔记（深入）”；
- 缓解方法：设置合理的 memory request/limit ratio（例如 limit = 1.2 × request），留出回收缓冲空间
- 避免在低内存容器（如 GODEBUG=madvdontneed=1 换确定性释放
- Kubernetes 1.22+ 支持
memory.swap控制，但 Go 程序不 swap，该配置对 Go 无效
真正难处理的是那种“分配快、释放慢、中间夹着大对象引用”的模式——MADV_FREE 再怎么优化，也救不了没及时切断的指针链。
