结合堆快照区分瞬时分配与长期持有

先给结论：瞬时分配看 alloc_space / alloc_objects，长期持有看 inuse_space / inuse_objects，是否持续持有还要用多张可比堆快照确认趋势。一次快照里某个函数的累计分配很高，并不等于它泄漏；只有对象经过垃圾回收后仍存活，并且同一分配栈在相近负载下持续增长，才值得按长期持有方向追查。

Go 的 heap profile 同时记录当前存活对象和进程启动以来的累计分配。默认查看的是 inuse_space，因此排查分配速率时必须显式切换样本索引，不能把默认视图当成全部答案。

Go 官方诊断文档：https://go.dev/doc/diagnostics

模式命名：双视图堆快照

我把这套方法称为“双视图堆快照模式”：第一类视图回答“这段时间一共分配了多少”，第二类视图回答“最近一次 GC 后还留下多少”。再用两个或多个时间点的快照比较同一分配栈，判断存活对象是在回落、保持稳定，还是持续增加。

同一段代码可能同时出现在四个视图中，但意义不同。例如 JSON 编码路径的 alloc_space 很高、inuse_space 很低，通常表示产生了大量短命对象；缓存插入路径的 inuse_space 连续增加，则说明对象没有及时退出可达集合。

适用压力：什么时候需要两类证据

以下现象最适合使用双视图，而不是只截一张 heap profile：

• 容器内存峰值很高，但请求结束后又明显下降；
• GC 次数和 CPU 开销增加，常驻内存却基本稳定；
• 服务运行时间越长，最近一次 GC 后的 live heap 仍不断抬升；
• 同一接口既有大缓冲分配，又有缓存、订阅表或队列长期保存对象；
• 优化后总分配下降，但 RSS 或存活堆没有同步下降。

Go 官方文档说明，heap profile 反映最近一次完成的垃圾回收时点，并有意省略更晚的新分配，避免把大量尚未回收的垃圾误算成长期存活。这正是比较快照前要对齐 GC 条件的原因。

四种样本索引回答四个不同问题

inuse_space 与 alloc_space 都以字节为单位，但一个是当前存活量，一个是累计分配量。对象数视图则能发现“每个对象很小、数量却非常多”的情况。排查时至少交叉看一次字节和对象数，避免只盯着大对象。

一个实用判断矩阵如下：

典型实现：采集两张可比较的堆快照

先在受控地址上启用诊断端口。下面示例把 pprof 单独监听在回环地址，避免直接暴露到公网；生产环境还应通过网络策略、身份认证或内部代理限制访问。

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof" // 注册 /debug/pprof/ 处理器到 DefaultServeMux
)

func startProfiler() {
	go func() {
		// 只监听回环地址，避免诊断入口直接暴露到外部网络
		if err := http.ListenAndServe("127.0.0.1:6060", nil); err != nil {
			log.Printf("pprof server stopped: %v", err)
		}
	}()
}

func main() {
	// 诊断服务应在业务服务启动前初始化
	startProfiler()
	select {}
}

接着选择两个可比较的业务窗口，例如同一版本、相近 QPS、相同缓存预热状态。不要用“刚启动的空闲实例”和“运行数小时的高峰实例”直接做结论。采集前使用 heap 端点的 gc=1 参数触发一次 GC，使两张快照都更接近回收后的存活集合。

# 预热完成且负载稳定后，触发一次 GC 并保存基线快照
curl -fsS 'http://127.0.0.1:6060/debug/pprof/heap?gc=1' \
  -o heap-a.pb.gz

# 经过同类业务窗口后，再用相同条件保存第二张快照
curl -fsS 'http://127.0.0.1:6060/debug/pprof/heap?gc=1' \
  -o heap-b.pb.gz

# 先分别查看两张快照的 live heap 排名前二十项
go tool pprof -sample_index=inuse_space -top -nodecount=20 heap-a.pb.gz
go tool pprof -sample_index=inuse_space -top -nodecount=20 heap-b.pb.gz

gc=1 会额外触发垃圾回收，频繁调用可能影响延迟，因此应在明确的诊断窗口中使用。若服务本身正处于 GC 风暴，也要记录采集时的 QPS、堆大小和 GC 次数，避免诊断动作改变观察对象。

比较 live heap 与累计分配

对于两张独立的存活堆快照，使用 -diff_base 更容易看到第二张相对第一张的增减。报告出现负值并不奇怪，它表示某个分配栈在第二张快照中的存活量下降。

# 比较两张 live heap，正值表示第二张快照中该栈存活更多
go tool pprof \
  -sample_index=inuse_space \
  -diff_base=heap-a.pb.gz \
  -top -nodecount=30 \
  heap-b.pb.gz

# 切换到对象数，识别大量小对象的长期持有
go tool pprof \
  -sample_index=inuse_objects \
  -diff_base=heap-a.pb.gz \
  -top -nodecount=30 \
  heap-b.pb.gz

对同一个进程按时间先后采集的累计指标，-base 可用于计算后一个累计 profile 减去前一个 profile 的增量。它适合回答“这段业务窗口新增了哪些分配”，而不是回答“哪些对象最终还活着”。

# 同一进程的累计字节后值减前值，观察窗口内新增分配来源
go tool pprof \
  -sample_index=alloc_space \
  -base=heap-a.pb.gz \
  -top -nodecount=30 \
  heap-b.pb.gz

# 累计对象数可揭示大量小对象分配，即使总字节不突出
go tool pprof \
  -sample_index=alloc_objects \
  -base=heap-a.pb.gz \
  -top -nodecount=30 \
  heap-b.pb.gz

如果 heap profile 来自不同进程、不同二进制或重启前后，累计值的起点已经不同，就不要直接用 -base 解释窗口增量。此时应保持相同压测脚本和时长，分别比较比例与热点，或为每次运行单独采集可控的 delta profile。

如何从分配栈落到代码

top 先找热点，top -cum 再看由调用链带来的累计影响，最后用 list 定位源代码行。一个函数自身 flat 值不高，但 cum 值很高，通常表示它调用了真正的分配热点。

# 先按累计值排序，找到把分配带入业务路径的上层函数
go tool pprof -sample_index=alloc_space -top -cum heap-b.pb.gz

# 将 ExampleHandler 替换为报告中的真实函数名，定位具体源码行
go tool pprof -sample_index=alloc_space -list='ExampleHandler' heap-b.pb.gz

找到代码行后再判断对象生命周期：临时 []byte 是否可以复用，字符串拼接是否制造中间对象，缓存是否缺少容量限制或过期删除，goroutine 是否通过闭包、channel、timer 或全局表间接保留大对象。不要看到某个标准库函数排在前面就直接修改它，调用者往往才是决定生命周期的地方。

反例：五种容易得出错误结论的做法

只看一张快照的绝对值

服务稳定运行时本来就会有常驻缓存、连接状态和编译后的模板。绝对值大不等于持续增长，至少要比较两个相近业务窗口。

把 alloc_space 高直接叫作泄漏

alloc_space 包括已经被 GC 回收的字节。它高说明分配多，可能带来 GC 成本，但不能证明对象仍被持有。

在不同负载、不同版本之间直接做差

请求类型、QPS、缓存命中率和二进制变化都会改变分配栈。基线不可比时，差异报告只是在描述两个实验，不是在证明一个泄漏。

把 RSS 与 Go live heap 视为同一指标

进程 RSS 还可能包含 goroutine 栈、运行时元数据、映射内存、cgo 分配和暂未归还给操作系统的页。heap profile 主要解释 Go 堆对象；当 RSS 增长而 inuse_space 稳定时，应继续检查运行时内存分类和非 Go 堆来源。

为了“精确”把采样率长期设为 1

内存 profile 默认是采样数据，较大的对象更容易被采到。把 runtime.MemProfileRate 设为 1 会记录所有分配，但可能显著拖慢程序。通常先用默认采样找热点，只在可控复现实验中短时提高精度。

后果：优化目标会因此不同

双视图的价值不只是把问题命名得更准确，它会直接改变优化动作：

• alloc 高、inuse 稳：减少临时对象、复用缓冲、预分配切片容量，目标是降低分配率与 GC 频率。
• inuse_space 增长：检查缓存上限、队列积压、引用链和生命周期，目标是缩小长期存活字节。
• inuse_objects 增长：检查小对象集合、map 项、订阅者、timer 和 goroutine 关联状态，目标是减少持续可达对象数。
• RSS 增长但 Go 堆稳定：不要继续盲改 Go 分配热点，转查栈、mmap、cgo 和运行时保留内存。

优化后仍用同样的负载和采集条件复测。只要对比条件改变，优化前后的百分比就失去直接可比性。

判断清单

1. 先定义问题：是内存峰值、GC 成本、常驻堆增长，还是进程 RSS 增长。
2. 记录条件：版本、实例、QPS、请求构成、缓存预热和采集时间窗保持可比。
3. 对齐回收：诊断窗口允许时，用 gc=1 采集回收后的 heap profile。
4. 切换四视图：至少同时查看一个 alloc 指标和一个 inuse 指标，并补充对象数视图。
5. 比较同一分配栈：同栈在多张 live heap 中持续增长，才进入长期持有排查。
6. 回到调用者：结合 top -cum 与 list 查清谁创建、谁保留、何时释放。
7. 原条件复测：优化前后使用同一采集方法，不用不可比实验宣称改善。

常见问题

为什么 heap profile 默认不是刚刚这一秒的全部分配？

官方说明 heap profile 以最近一次完成的 GC 为统计时点，并省略更晚的新分配，以免把尚未回收的垃圾偏向性地算入 live heap。需要观察累计分配时，应切换到 alloc_space 或 alloc_objects。

两张 inuse_space 都很大，就一定有泄漏吗？

不一定。缓存、索引和连接状态可能形成稳定常驻集。关键是同一负载下是否继续增长，以及增长是否集中在同一分配栈。

应该优先看字节还是对象数？

内存容量问题先看字节，GC 扫描和大量小对象问题补看对象数。两者一起看，才能区分少量大对象与海量小对象。

只用一次 gc=1 能排除瞬时对象吗？

它能让快照更接近回收后的存活集合，但不能替代趋势比较。对象可能跨过一次 GC 后很快释放，也可能只在特定请求下长期保留，因此仍要在相近业务窗口重复采集。

总结

区分瞬时分配与长期持有，核心是把“累计发生过”与“现在仍存活”分开。alloc_space 和 alloc_objects 用来定位分配压力，inuse_space 和 inuse_objects 用来描述 live heap，多张可比快照则把单点数据升级为生命周期证据。

先对齐负载、版本和 GC 条件，再比较同一分配栈的变化。这样既不会把正常的短命分配误判为泄漏，也不容易漏掉缓存、队列和引用链造成的长期持有。