会，但阻塞时间极短，通常在纳秒到微秒级；它触发轻量级 GC 状态快照，引发受控 STW，不执行完整 GC，高频调用仍需谨慎。
runtime.ReadMemStats 会阻塞吗？
会，但阻塞时间极短，通常在纳秒到微秒级。它触发一次轻量级的 GC 状态快照采集，不触发完整 GC，但会暂停所有 goroutine 的执行（STW），只是持续时间远短于一次真正的 GC。
- 这个 STW 是 runtime 内部的、受控的，一般无需担心
- 高频调用（比如每毫秒一次）仍可能累积可观开销，尤其在 GC 压力大时
- 生产环境监控建议控制在每秒 1–10 次，避免干扰调度器行为
示例中常看到 runtime.ReadMemStats(&ms)，&ms 必须传地址，否则结构体复制后字段全为零值。
MemStats 中哪些字段真正反映“当前堆内存占用”？
真正反映实时堆内存使用的是 HeapAlloc 和 HeapInuse，不是 TotalAlloc 或 Sys：
-
HeapAlloc：当前已分配且未被回收的字节数（最常用指标） -
HeapInuse：堆中已被 runtime 占用的内存（含未被 Go 对象使用的空闲 span） -
TotalAlloc：程序启动以来累计分配的字节数（会一直增长，不能反映当前压力） -
Sys：Go 向操作系统申请的总内存（含堆、栈、内部结构等，远大于实际使用）
别用 Sys 判断 OOM 风险——它包含大量预留但未使用的虚拟内存；也别把 NextGC 当成硬阈值，它只是 GC 触发目标，实际触发时机还受 GOGC 和堆增长速率影响。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么两次 ReadMemStats 结果几乎一样？
常见原因有三个：
- GC 刚完成不久，堆尚未显著增长，
HeapAlloc变化小 - 程序大部分内存由全局变量或逃逸到堆的大对象占据，生命周期长，短期无波动
- 采样间隔太短（如 <10ms），而 Go 的内存分配和回收有批处理机制，变化被平滑掉了
验证方法：在分配明显内存后（比如 make([]byte, 1）立刻调用一次 <code>runtime.GC()，再读 HeapAlloc，就能看到回落；但注意 runtime.GC() 本身是强阻塞操作，仅用于调试。
ReadMemStats 在 CGO 或 syscall 场景下是否可靠？
基本可靠，但要注意两点：
- 它只统计 Go runtime 管理的内存，不包含 C 分配的内存（如
malloc、C.CString返回的缓冲区） - 如果程序重度依赖
unsafe手动管理内存或绕过 runtime（比如自定义 allocator），MemStats就完全不体现这部分开销
典型陷阱：用 C.malloc 分配了上百 MB，HeapAlloc 却只有几 MB——这不是 bug，是设计如此。此时需额外监控 top 的 RES 或用 pprof 的 heap -inuse_space + cgo 标签组合分析。
真实内存压力从来不止在 Go 堆里。尤其是长期运行的服务，C 侧泄漏比 Go 侧更难察觉，而 runtime.ReadMemStats 对它完全沉默。
