Go pprof alloc_space 和 inuse_space 为什么结论相反

会出现“结论相反”，通常不是 pprof 算错，而是把两个不同问题混在了一起：inuse_space 问“采样时还有多少字节活着”，alloc_space 问“进程启动后总共分配过多少字节”。短命对象会把累计分配推高，却不会长期占住堆；少量长期对象则可能让存活内存排名靠前。

先记住：排查内存占用、疑似泄漏和堆峰值，优先看 inuse_space；排查分配抖动、频繁创建临时对象和 GC 压力，再看 alloc_space。两个视图要用同一份 profile 交叉判断。

三个速记点：inuse 是存活字节，alloc 是累计字节；heap profile 以最近一次完成的 GC 为重要观察点；pprof 是采样剖析，数值适合定位热点，不是逐对象账本。

先看懂两个视图到底在统计什么

Go 官方文档把这两个字段放在同一组 sample index 中，但统计生命周期不同。inuse_space 只保留当前仍存活对象占用的空间，适合观察缓存、全局引用、未释放的请求状态等“现在还占着”的内存。alloc_space 则累计程序启动以来分配过的总字节，已经被 GC 回收的临时对象也会计入。

因此，一个 JSON 解码函数每次请求创建 1 MB 临时缓冲，最后只留下很小的结果：它可能在 alloc_space 排名很高，在 inuse_space 却很低。反过来，一个只分配一次但一直被缓存引用的对象，累计分配不一定夸张，却会稳定出现在 inuse_space 前列。

同一份 profile 要用两个视图交叉看

不要只依赖默认显示。可以先采集一份 heap profile，再显式切换视图：

package main

import (
	"log"
	"os"
	"runtime/pprof"
)

func main() {
	// 写出 heap profile；它用于后续比较两种 sample_index。
	file, err := os.Create("heap.pprof")
	if err != nil {
		log.Fatal(err)
	}
	defer func() {
		// 关闭文件，确保 profile 写入完成并释放句柄。
		if err := file.Close(); err != nil {
			log.Print(err)
		}
	}()
	if err := pprof.WriteHeapProfile(file); err != nil {
		log.Fatal(err)
	}
}

# 先看仍存活的字节，定位当前占用和保留关系
go tool pprof -sample_index=inuse_space ./app heap.pprof

# 再看累计分配的字节，定位短命对象和分配抖动
go tool pprof -sample_index=alloc_space ./app heap.pprof

进入 pprof 后可用 top 查看排序，也可以用 list 回到具体函数。两次的调用栈相同并不表示答案必须相同：排序字段变了，排名自然可能变化。

排名相反时，先对照对象生命周期

还要记住 heap profile 不是任意时刻的完整快照：官方实现以最近一次完成的 GC 为统计参考，并会避开更近的分配对存活数据造成偏斜。如果采集前几乎没有发生 GC，结果的解释边界又不同。比较两次采样时，应尽量保持相似的请求负载和采集时机。

按问题类型选择最终结论

用户投诉“服务占用越来越大”时，先看 inuse_space，并确认同一对象类型是否在多次采集后持续增长；不要因为 alloc_space 很高就直接判定泄漏。用户遇到 GC 频繁、吞吐下降或延迟抖动时，再看 alloc_space，重点是单位时间内哪些调用栈制造了大量短命对象。

最后做一次复查：分别记录两个视图的 sample index、采集时是否完成 GC、关键调用栈、对象数以及负载条件。这样“排名相反”会变成生命周期证据，而不是互相矛盾的两张榜单。

常见问题

alloc_space 是当前堆大小吗？不是。它是进程启动以来累计分配的字节，包含已经回收的对象；当前存活空间应看 inuse_space。

默认打开 heap profile 看哪个指标？pprof 默认显示 inuse_space；需要分析累计分配时显式指定 -sample_index=alloc_space，避免误读。

为什么两次 profile 的数字不能简单相减？因为采样率、GC 时点、请求负载和进程生命周期都会影响样本。应保持采集条件，并把趋势与调用栈一起解释。