runtime.GC()仅触发垃圾回收标记清理，不归还内存给OS；debug.FreeOSMemory()才尝试将空闲span归还OS，但需满足可达对象清空、span连续且未被sync.Pool等持有等条件。
runtime.GC() 和 debug.FreeOSMemory() 的作用根本不同
runtime.GC() 只是触发一次垃圾回收循环，标记并清理不可达对象，把内存块标记为“可复用”；它不碰操作系统层，Sys 字段（总内存占用）几乎不变。debug.FreeOSMemory() 才真正尝试调用 madvise(MADV_DONTNEED)（Linux）或等效系统调用，把 runtime 管理的空闲页归还给 OS。但它不是“二次 GC”，也不会移动存活对象——只退那些已空闲、连续、且未被缓存结构（如 sync.Pool）持有的 span。
FreeOSMemory() 没效果？先检查这三个硬条件
常见现象：调了 debug.FreeOSMemory()，/proc/<pid>/statm</pid> 的 RSS 毫无变化。这不是函数失效，而是没满足释放前提：
- 堆上仍有大量“可达但闲置”的对象（比如全局
map里塞着旧数据，key 没删，GC 不会动它们） - 空闲 span 太小或太碎——
debug.FreeOSMemory()只退整页（4KiB）对齐的连续空闲 span，碎片化严重时无 span 可退 - 用了
bytes.Buffer、sync.Pool或unsafe分配的内存，这些不走 mheap，FreeOSMemory()完全看不见
怎么验证是否真还回去了？别只看 top 或 ps
靠外部工具（如 top、ps）看 RSS 不够准，尤其在容器中受 cgroup 统计延迟影响。正确验证路径是：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先调
runtime.GC()，确保 GC 已完成 - 再调
debug.FreeOSMemory() - 立即执行
runtime.ReadMemStats(&m)，检查m.HeapReleased是否增长——只有它涨了，才说明 OS 层真收到了内存 - 对比
m.Sys：若HeapReleased涨但Sys不降，可能是内核延迟归还，或该内存被 mmap 映射而非 heap 分配
绝大多数场景下，你根本不该手动调用它
Go 运行时默认会在空闲 span 超过约 5 分钟后自动归还（由 scavengelimit 控制），且 Go 1.12+ 支持 GODEBUG=madvdontneed=1 让每次 GC 后自动尝试归还，比手动调更平滑。强行高频调用 debug.FreeOSMemory() 会导致 STW 时间显著拉长，反而拖慢服务响应。真正值得用的场景极少：
立即学习“go语言免费学习笔记（深入）”；
- 长期运行的服务刚扛过突发流量高峰，确认后续数小时负载极低，且 RSS 高到可能触发 Kubernetes OOMKilled
- 本地调试时想快速验证某段逻辑是否真导致内存堆积（配合 pprof +
cat /proc/pid/statm） - Windows 下基本无效——
VirtualFree()行为与 Linuxmadvise不同，跨平台代码里写它等于白费
最常被忽略的一点：FreeOSMemory 不是“清内存”，而是“退租空房间”。如果房间里还有东西（存活对象）、或者房间太小（碎片）、或者这房间根本不是 runtime 租的（Pool/Buffer/mmap），它就什么也干不了。
