Go pprof 怎样从内存剖析定位保留对象

线上服务的内存曲线持续走高时，我通常不会先去猜“是不是某个切片忘了清空”。更可靠的做法是先拿一份 Go heap profile，再把当前仍在堆上占空间的对象和历史累计分配拆开看。pprof 的 inuse_space、inuse_objects 适合回答“现在还有什么被保留”，而 alloc_space、alloc_objects 更适合回答“过去总共分配过什么”。

官方地址：https://go.dev/doc/diagnostics

定位保留对象的关键不是找到一条看起来很高的调用栈，而是用同一口径采集前后 profile，先确认增长是否在负载结束后仍然存在，再沿引用相关的调用路径回到代码。

先把当前保留与历史分配分开

我第一次看 heap profile 时，最容易把“分配很多”误当成“现在还占很多”。这两个问题对应不同的样本索引：inuse_space 统计采样时仍在使用的空间，inuse_objects 统计仍在使用的对象数；alloc_space 和 alloc_objects 则把生命周期内的累计分配放在一起。一个短命但频繁创建的临时对象，可能在 alloc 视图很高，却不会成为长期保留对象。

因此，标题所说的“保留对象”要先落到一个明确口径：优先从 inuse_space 找占用内存的路径，再用 inuse_objects 判断是否是大量小对象。两者结论不同并不矛盾，反而能帮助判断是少量大对象、还是对象数量膨胀。

采集可以对比的 heap profile

如果服务使用了 net/http/pprof，可以从诊断端点取得 heap profile；如果问题只出现在基准测试，也可以让 go test 写出内存剖面。关键是给每份文件标记采集时刻、负载阶段和 profile 口径，不要把一次随手抓取的结果当成泄漏结论。

# 先保存当前 heap 样本，文件名带上采集阶段便于和基线比较
curl -o heap-before.pb.gz 'http://127.0.0.1:6060/debug/pprof/heap'

# 用相同的请求或批处理负载后再保存一份样本
curl -o heap-after.pb.gz 'http://127.0.0.1:6060/debug/pprof/heap'

# 交互查看当前仍在使用的空间，先从最大路径开始阅读
go tool pprof -sample_index=inuse_space heap-after.pb.gz

上面的地址只是常见的本地诊断入口，生产环境应把 pprof 暴露在受控的内部网络，并根据实际服务端口和路径调整。Go 官方文档说明 heap profile 是内存分配样本，pprof 工具负责过滤和可视化；所以 profile 能帮助我们定位高概率路径，但不是逐个对象的完整转储。

如果采集的是测试基准，可以把 profile 与测试命令绑定，方便复现同一负载：

# 基准测试同时留下 CPU 和内存剖面，便于对照分配热点
go test -cpuprofile cpu.prof -memprofile mem.prof -bench .

# mem.prof 可以继续用 pprof 查看；选择索引时仍要说明口径
go tool pprof -sample_index=inuse_space mem.prof

从 top 到 list 沿调用路径定位

我会把分析分成两层。第一层用 top 找到占用空间或对象数最高的函数，第二层用 list 把函数内的分配位置展开。不要一上来就打开复杂图形：先确认索引、总样本和前几名路径，再决定是否需要调用图。

# 进入交互式 pprof 后，先按当前仍占用的空间排序
go tool pprof -sample_index=inuse_space heap-after.pb.gz
(pprof) top

# 把第一批可疑函数展开到源码行，寻找保留容器或缓存写入点
(pprof) list loadUserCache

# 需要看调用关系时再生成图；图形工具不可用时仍可使用 top 和 list
(pprof) web

top 中的函数名只是样本归因点，不等同于“这个函数拥有对象”。例如一个缓存构造函数可能负责创建值，但真正让对象长期存活的是全局 map、长生命周期结构或仍未结束的请求引用。读 list 时，我会继续问三个问题：写入了哪个容器？容器的生命周期是谁管理？在一次负载结束后，是否有明确的删除或替换动作？

如果 inuse_space 排名靠前而 inuse_objects 不高，优先检查大缓冲区、响应体缓存和批量结果；如果对象数很高但空间占用分散，优先检查每请求创建的 map、标签、闭包或索引项是否被某个长生命周期容器挂住。这个判断只是排查方向，最终仍要结合代码中的释放条件。

用基线差异排除正常增长

单份 profile 很难证明泄漏。我更愿意把它放进一个最小实验：先让服务完成预热，保存 heap-before.pb.gz；用相同请求量运行一段负载，保存 heap-after.pb.gz；负载停止后再等一个稳定窗口，保存第三份。若某条路径只在预热阶段出现，可能是缓存建立；若负载停止后仍持续保留并随轮次增长，才值得继续追踪。

# 将后一次 profile 与基线做差异分析，减少固定初始化对象的干扰
go tool pprof -sample_index=inuse_space \
  -base=heap-before.pb.gz heap-after.pb.gz

# 先看差异最大的函数，再回到源码确认引用关系
(pprof) top
(pprof) list loadUserCache

分析基线时要保持口径一致：相同的 sample_index、相近的运行阶段、相同或可解释的请求输入。不要用 inuse_space 的前一份结果去和 alloc_space 的后一份结果相减，也不要只凭 profile 文件大小变化下结论。

补上采样和生产取样边界

heap profile 使用采样数据，图上的数值是用于估算和归因的信号，不应被解读成完整对象清单。Go 诊断文档还提醒，不同诊断工具可能互相影响；在同一时间收集多个 profile 时，应留意额外开销和结果口径。生产环境更适合选择一个副本、在受控窗口取样，并把单次结果保存下来做比较。

还有几个我会写进排查记录的边界：

• 不要把 alloc_space 最高的路径直接称为泄漏，它可能只是高频短命分配。
• 不要把单次 inuse_space 峰值直接称为长期保留，先看负载停止后的回落趋势。
• 不要同时开启会互相干扰的多类精细剖析后再比较细小差异，先保持一次只采一个主要 profile。
• 不要把 profile 的采样结果当成对象级审计；需要确认具体引用时，仍要回到代码和生命周期设计。

最后用一张清单判断定位是否完成

当我准备提交修复时，会确认：是否先定义了“保留”的索引口径；是否有负载前后的同口径 profile；是否用 top 和 list 找到了源码位置；是否解释了容器为什么仍然持有引用；是否检查了负载停止后的趋势；是否把正常缓存与无界增长分开；是否记录了采样和生产取样的限制。只有这些问题都能回答，pprof 图才真正变成了可执行的修复线索。

相关问题

• 为什么 alloc_space 很高但内存没有一直上涨？因为累计分配包含已经回收的短命对象。
• 只看 inuse_space 够吗？不够，结合 inuse_objects 才能区分少量大对象和大量小对象。
• heap profile 能直接告诉我是哪一条引用没释放吗？不能，它先提供采样归因路径，引用生命周期仍要回到代码确认。