Go pprof heap 报告无法定位泄漏的采集步骤

Go pprof 的 heap 报告定位不了“泄漏”，先不要急着换命令。最常见的原因是把 inuse 和 alloc 当成同一个指标，或者两次采集使用了不同的负载窗口和采样率。正确的顺序是：先固定采集入口与时间，再分别查看当前仍存活的对象和累计分配，最后回到源码行确认。

官方文档：https://pkg.go.dev/net/http/pprof

本文只讨论 inuse、alloc 与采样率。图中的框和连线是原创结构说明图，不是运行截图，也不代表某个服务已经实际产生了图示结果。

先把 heap 采集窗口固定下来

线上服务可以通过 net/http/pprof 暴露标准处理器。采集时不要把一次临时高峰和另一份空闲时段报告直接比较，至少记录服务版本、业务负载、采集时间和请求入口。heap 端点返回当前进程的堆剖析数据，gc=1 可以在采集前请求一次垃圾回收，用来减少刚刚不可达对象对当前存活量的干扰；它不是“修复泄漏”的开关。

import (
    "log"
    "net/http"

    // 通过副作用注册 /debug/pprof/ 下的标准处理器。
    _ "net/http/pprof"
)

func startProfileEndpoint() {
    // 只把调试入口绑定到受控地址，避免把剖析接口直接暴露给公网。
    go func() {
        if err := http.ListenAndServe("127.0.0.1:6060", nil); err != nil {
            log.Printf("pprof server stopped: %v", err)
        }
    }()
}

采集命令要把“文件名”和“窗口”写清楚。没有 seconds 时，heap 是某一时刻的快照；带上 gc=1 后，得到的是回收动作之后的快照。

# 采集回收后的 heap 快照，文件名包含负载阶段，便于和下一次对比。
go tool pprof -proto "http://127.0.0.1:6060/debug/pprof/heap?gc=1" > heap-after-gc.pb.gz

# 先看报告支持哪些样本类型，再选择要看的指标。
go tool pprof -sample_index=inuse_space heap-after-gc.pb.gz

用 inuse 判断“现在还留着什么”

inuse_space 关注当前仍在使用的字节数，inuse_objects 关注当前仍在使用的对象数。排查疑似泄漏时先看这两列：如果同一业务窗口反复采集后某个调用路径的 inuse 持续抬升，才值得继续追它的引用和生命周期。

# 以当前仍占用的空间排序，先找大块保留对象来自哪里。
go tool pprof -sample_index=inuse_space heap-after-gc.pb.gz

# 在 pprof 交互界面中执行：
top             # 先看聚合后的热点函数
list loadCache  # 再回到函数源码行，看哪一行保留了对象
web             # 需要调用关系时打开图形视图

不要只看一个“大数字”。大对象可能来自一次正常缓存预热；很多小对象则可能表现为 inuse_objects 高而 inuse_space 不高。把空间和对象数一起看，才能区分“少量大对象”和“大量小对象”两类问题。

用 alloc 找“谁一直在分配”，不要把它直接当泄漏

alloc_space 和 alloc_objects 统计的是累计分配视角。一个函数的 alloc 很高，说明它在采集窗口内制造过很多分配；这些对象后来可能已经被回收。因此 alloc 适合寻找分配压力和短生命周期热点，不能单独证明对象被长期保留。

# 用累计分配空间寻找制造临时对象最多的路径。
go tool pprof -sample_index=alloc_space heap-after-gc.pb.gz

# 用累计对象数观察“小对象风暴”，再回到源码行定位构造点。
go tool pprof -sample_index=alloc_objects heap-after-gc.pb.gz

一个实用判断是：inuse 高且持续上升，优先怀疑保留链；alloc 高但 inuse 稳定，优先检查重复序列化、临时切片、转换和缓存淘汰压力。两者都高时，再按调用链拆分出“分配位置”和“保留位置”是否是同一处。

统一 MemProfileRate，再比较多份报告

内存 profile 使用采样，不是把每一次分配都完整记录。runtime.MemProfileRate 表示平均采集多少字节分配一次；设置为 0 会关闭内存剖析。降低采样间隔通常能让小对象更容易出现，但也会增加开销。要比较两份报告，必须在同一个进程启动阶段使用同一配置，否则差异可能只是采样率不同。

package main

import "runtime"

func configureMemoryProfile() {
    // 在业务分配发生前统一采样间隔；生产环境应评估额外开销。
    runtime.MemProfileRate = 64 * 1024
}

调试时可以先用默认配置建立基线，只有小对象热点长期不可见时才针对性降低采样间隔。不要在一次对比中途动态改变配置，也不要拿“采样率未知”的历史文件和新文件直接做增长结论。

最后用重复采集确认，而不是凭一张图下结论

建议至少做三次同窗口采集：预热后一次、稳定负载中一次、处理完同一批任务后一次。每次都固定 sample_index，先对比 inuse_space 和 inuse_objects，再用 alloc 解释分配来源。只有 inuse 在相同边界下持续增加，且能回到同一调用路径，才把它升级为“疑似泄漏”继续检查引用关系。

常见问题

为什么 heap 的 alloc 很高却看不到内存增长？

因为 alloc 是累计分配视角，短生命周期对象也会计入；此时应回到 inuse 和多次快照判断是否真的有保留增长。

采样率越低越好吗？

不是。更密集的采样有助于观察小对象，但会增加剖析开销。排查时最重要的是统一配置、统一窗口，再解释差异。

总结：先固定采集，再用 inuse 找保留对象、用 alloc 找分配来源，最后统一 MemProfileRate 并重复比较。这样得到的是可复核的排查线索，而不是把一张 heap 图误判成泄漏证据。