Go pprof heap 采样数量偏小的解释

看到 Go 的 heap profile 里只有很少几条记录时，先别把“记录条数”当成“对象数量”。heap profile 是按分配字节进行抽样，再把样本加权后呈现热点；它回答的是“哪些调用位置贡献了多少内存”，不是把每个对象逐一列出来。本文只解释 profile 指标口径，帮助你判断这份数据到底在描述存活内存，还是描述一段时间内的累计分配。

官方资料：https://go.dev/doc/

样本条目偏少通常是抽样粒度和聚合方式的结果。先选择正确的 sample index，再看加权后的 bytes 或 objects；只有在需要比较采样密度时，才讨论 runtime.MemProfileRate。

本文的结论可以压缩成三句话：样本条目不是实际分配次数；inuse_* 看当前仍存活的对象，alloc_* 看累计分配；profile 中的数值是采样估计，不应直接当成精确账本。

先把“样本少”拆成三个问题

heap profile 的原始观察单位是采样记录。运行时不会为每一次分配都保存完整调用栈，而是按照分配字节进行抽样，并把相近的调用栈聚合到一起。因此，短生命周期对象很多时，最终看到的 profile 条目仍可能不多；这不表示这些对象没有发生过分配。

读图时可以把关系分成两层：runtime.MemProfileRate 影响采样密度，采样器得到的记录会形成加权样本，随后 pprof 再按调用栈汇总到 heap profile。inuse_space 和 alloc_space 是汇总后的指标，不是“还剩多少条样本”。

所以，先问“条目少不正常”往往问错了。更有用的问题是：这些条目是否覆盖了我关心的调用位置，以及我选的指标是否和排查目标一致。

inuse 与 alloc 不是同一个问题

pprof 常见的四个指标可以按“存活”和“累计”分成两组：

• inuse_space：当前仍被占用的字节数，适合找当前堆占用较大的调用位置。
• inuse_objects：当前仍存活的对象数，适合关注对象数量而不是字节大小。
• alloc_space：从采样开始累计分配的字节数，适合观察分配流量和短命对象制造者。
• alloc_objects：从采样开始累计分配的对象数，适合观察分配次数较多的调用位置。

例如，一个解析函数不断创建短命小对象，profile 中的 alloc_objects 可能很突出，但这些对象已经被回收后，inuse_objects 并不会同样突出。反过来，一个缓存保留少量大对象，inuse_space 可能很高，alloc_objects 却不高。

用 sample index 固定问题口径

同一份 profile 可以用不同的 sample index 阅读。排查“当前内存为什么高”时，先看 inuse_space；排查“谁制造了大量分配”时，再看 alloc_space 或 alloc_objects。如果只看默认视图，很容易把“当前保留”误读成“历史累计”。

# 用存活字节定位当前堆占用
go tool pprof -sample_index=inuse_space heap.out

# 用累计字节定位一段时间内的分配流量
go tool pprof -sample_index=alloc_space heap.out

# 只改变阅读的指标，不会把 profile 变成逐对象明细

命令中的 sample_index 只是选择报告视角。它不会让样本数量突然变多，也不会把采样结果变成精确的对象清单。比较两次 profile 时，还要保持采样方式和观察窗口相近，否则指标变化可能来自口径不同。

MemProfileRate 影响密度，不负责解释一切

runtime.MemProfileRate 表示运行时希望平均每分配多少字节记录一次样本。数值越小，理论上采样更密；数值越大，开销更低但细小分配更容易在报告中显得稀疏。它影响“记录哪些分配”，不改变 inuse 与 alloc 两组指标的语义。

package main

import "runtime"

func prepareHeapProfile() {
	// 只在需要更密的诊断窗口设置采样率，生产环境要评估额外开销。
	runtime.MemProfileRate = 64 * 1024
}

调整采样率后不要把新旧 profile 的绝对数值直接横向拼接。更稳妥的做法是先记录采样率，再在相同 workload 和相同指标下比较趋势；如果目标是定位当前保留内存，优先比较 inuse_space，如果目标是找分配制造者，优先比较 alloc_space。

一套不容易误读的阅读顺序

1. 先记下 profile 的采集时间段和采样率，确认比较对象的口径一致。
2. 把“条目数量”放到次要位置，先选择 inuse_space、inuse_objects、alloc_space 或 alloc_objects。
3. 用 bytes 判断内存体量，用 objects 判断对象数量；不要用一个指标替代另一个指标。
4. 最后再看调用栈聚合后的热点，结合业务生命周期判断它是长寿命对象，还是短命分配流量。

常见误区有两个：一是看到样本少就认为 pprof 丢了大部分对象，二是看到 alloc_space 很高就直接断言存在内存泄漏。前者忽略了抽样和聚合，后者混淆了累计分配与当前存活。只有 inuse_* 在相近观察窗口持续上升，才值得进一步沿着对象生命周期排查。

相关问题

为什么 alloc_space 很高但 inuse_space 不高？

这通常说明分配流量大，但对象生命周期短，采样窗口结束时大部分对象已经回收。它更像分配 churn 信号，不等于泄漏。

只看 inuse_objects 可以判断内存占用吗？

不能。对象数量相同，单个对象大小可能差异很大；判断堆占用应同时关注 inuse_space，需要对象规模时再结合 inuse_objects。

小结

Go pprof heap 中样本条目偏小，首先要从采样与聚合机制解释，而不是把它当成实际对象数。把 inuse_* 用于当前存活，把 alloc_* 用于累计分配，再用 sample_index 固定观察口径，最后才讨论 MemProfileRate 的密度影响，基本就能避免“样本少”和“数据少”之间的误判。