Go 内存分析要“动大手术”了：pprof 提案拟为 heap profile 补上失踪的另一半
内容提要
Go团队提案为heap profile新增memory_space采样类型，解决RSS与堆快照不一致的问题。该类型不新建profile，默认展示从RSS到Go内存、非Go内存、存活堆、死堆、协程栈及运行时开销的完整层级归因，并明确告警RSS不可用等情况。代价是profile体积增大约30%，压缩后约10%。提案已临时通过，待正式实现验证。
延伸解读
为什么堆快照总比 RSS 小？
默认 GOGC=100 时，堆内存会膨胀到存活对象的两倍左右，大量已死亡但未清扫的“死堆”不被 inuse_space 统计。此外，协程栈、运行时元数据、可执行文件、共享库、mmap 区域和 cgo 分配等非 Go 内存也不在 heap profile 中。因此存活堆常不到进程真实内存的一半，导致监控 RSS 与 pprof 堆快照严重脱节。
memory_space 如何补全另一半？
提案不新建独立 profile，而是给现有 heap/alloc profile 增加 memory_space 采样类型并设为默认展示。它构建从 RSS 到 Go Memory、Non-Go Memory、存活堆、死堆、协程栈及运行时开销的完整层级树。当 RSS 不可用或 Go Memory 大于 RSS 时，会显示明确警告而非误导性数字，帮助开发者直接定位非 Go 内存的占比。
体积代价与兼容性权衡
由于 pprof 格式要求所有采样携带全部采样类型字段，新旧采样调用栈不完全重合时样本数可能翻倍，预计未压缩体积增加约 30%，压缩后约 10%。社区正讨论通过 GOEXPERIMENT 或 GODEBUG 开关提供退出通道。持续性能剖析平台和 APM 厂商需提前评估存储与传输成本，而普通交互式用户则能获得更完整的视图。
当前进展与落地风险
该提案已获“临时通过，等待正式实现验证”，尚未合入主线。评审委员会希望看到经过正规工程打磨的实现，确认没有隐藏的坑后才会定案。RSS 读取依赖系统调用，无法放入 STW 窗口，方案选择在标记终止后尽快读取，接受一定时间偏差。开发者可关注 issue #79179 及早期原型 CL 的后续动态。
Q&A
为什么 Go 的 heap profile 抓出来的内存比容器 RSS 小很多？
因为默认的 inuse_space 只统计存活堆，即当前仍被引用、尚未被判定为垃圾的对象。在默认 GOGC=100 下，堆内存会在触发下一轮 GC 前持续膨胀到存活对象的两倍左右，大量已死亡但未清扫的内存（死堆）不会出现在 heap profile 里。再加上协程栈、运行时元数据、可执行文件、共享库、mmap 区域、cgo malloc 等非 Go 内存，真实 RSS 往往是 heap profile 数字的两倍以上。
Go 提案中的 memory_space 采样类型是什么？它和新建 profile 有什么区别？
memory_space 是提案为现有 heap/alloc profile 新增的一种采样类型，并设为默认展示类型。它不新建独立 profile，而是直接扩展现有 heap profile，因此用户照常调用 pprof.Lookup("heap").WriteTo(f, 0) 就能看到升级后的完整视图。这样做既提升了发现性，又不会破坏持续性能剖析等现有生态。
memory_space 采样类型展示的内存层级结构是怎样的？
它展示从 RSS 到具体调用栈的完整层级树：顶层是 RSS，然后分为 Go Memory 和 Non-Go Memory；Go Memory 下再细分 Heap（Live / Dead）、Stack、Runtime 等。如果 OS 能读到 RSS 且 RSS ≥ Go Memory，才会显示顶层 RSS 帧，并把 Non-Go Memory 计算为 RSS - Go Memory；如果 RSS 不可用或出现 Go Memory > RSS 的反常情况，则只展示 Go Memory 部分，并在根节点给出明确警告。
新增 memory_space 采样类型会带来哪些代价？
主要代价是 profile 体积增大。由于 pprof 格式要求同一份 profile 里所有采样都携带全部采样类型的字段，如果新旧采样类型的调用栈集合不完全重合，样本数量可能翻倍。预计未压缩体积增加约 30%，压缩后增加约 10%。社区正讨论通过 GOEXPERIMENT 或 GODEBUG 开关提供退出通道，长期方案则寄望于配套的 Recorder 提案。
为什么这个采样类型最终叫 memory 而不是 rss？
提案最初打算叫 rss，后来改为更中性的 memory。核心开发者曾担心 memory 显得含糊，但社区反馈（尤其是容器化基础设施背景的开发者）指出：Kubernetes 的 resources.limits.memory、cgroup v2 的 memory.current、docker stats 的 MemUsage、container_memory_working_set_bytes 等主流指标体系都以 memory 作为统一术语，再从中细分具体口径。Go runtime 自己的指标体系也是 /memory/classes/... 的命名风格，用 memory 反而与整个生态语言习惯一致。
这个提案目前的进展如何？什么时候能用上？
该提案编号为 #79179，在最新一期 proposal review 会议纪要中已被标记为 active，并获得“临时通过（provisionally accepted pending implementation）”的评审结论。评审委员会明确表示，希望看到一份经过正规工程打磨的实现，确认没有隐藏的坑之后才会真正定案。目前尚未合入主线，感兴趣的开发者可以持续关注 issue #79179 以及作者早期提交的原型 CL。
