Go MemStats HeapAlloc 与 HeapInuse 有什么区别

我排查 Go 服务内存上涨时，最容易先看见的是 runtime.MemStats 里的 HeapAlloc 和 HeapInuse。它们都以字节为单位，却不在同一层：前者描述已经分配给堆对象的字节，后者描述至少放着一个对象的 in-use span 容量。两者不能互换，更不能直接拿 HeapInuse 当作进程 RSS。

实际判断可以先记住一句话：HeapAlloc 更接近“对象用了多少”，HeapInuse 更接近“运行时占用了多少仍在使用的堆 span”。如果 HeapInuse - HeapAlloc 变大，首先想到的是 size class 空间和内部复用效率，而不是立刻下结论说出现了内存泄漏。

一句话结论：HeapAlloc 看对象字节，HeapInuse 看 in-use span 字节；差值只是特定 size class 未被对象占用部分的上界估计，排查内存问题必须再结合 HeapSys、HeapIdle、HeapReleased 和进程外内存。

HeapAlloc 和 HeapInuse 看的不是同一层

Go 的堆不是一块按对象大小随意切割的连续字节数组。运行时把堆虚拟地址划分成 span；一个 in-use span 至少包含一个堆对象，同时可能还留有可供同类大小对象使用的空间。于是，两个指标的观察对象不同：

• HeapAlloc：当前已经分配的堆对象字节数。对象不可达后，也可能在 GC 尚未完成清扫前暂时仍计入其中。
• HeapInuse：当前 in-use spans 的字节数。只要 span 里至少还有一个对象，它对应的容量就可能算在这里。
• HeapInuse - HeapAlloc：官方文档把它描述为已经分配给特定 size class、但目前没有被对象使用的空间估计，而且只是碎片的上界；这部分通常仍可被高效复用。

举一个不带具体运行读数的抽象例子：一个 span 里放着三个对象，它们合计占用 6 KB，但这个 span 的 in-use 容量是 8 KB，那么这 8 KB 更接近 HeapInuse，6 KB 更接近 HeapAlloc。剩下的 2 KB 不是“丢失的对象”，而是由分配粒度和 size class 带来的可复用空间。真实数据还会受到多个 span、不同大小类别和 GC 清扫时机影响。

用 ReadMemStats 读取时，先看组合而不是单值

采集这两个字段不需要访问运行时内部结构，公开 API 就够了。下面的函数只负责读取快照并计算差值；它没有把差值包装成固定阈值，因为阈值必须结合服务的分配模式、负载和时间序列来判断。

package main

import (
	"fmt"
	"runtime"
)

type heapSnapshot struct {
	heapAlloc  uint64
	heapInuse  uint64
	inuseSlack uint64
}

func readHeapSnapshot() heapSnapshot {
	var stats runtime.MemStats
	runtime.ReadMemStats(&stats) // 读取当前分配器统计快照。

	var slack uint64
	if stats.HeapInuse >= stats.HeapAlloc {
		slack = stats.HeapInuse - stats.HeapAlloc // 只把差值当作诊断线索。
	}

	return heapSnapshot{
		heapAlloc:  stats.HeapAlloc,
		heapInuse:  stats.HeapInuse,
		inuseSlack: slack,
	}
}

func main() {
	snapshot := readHeapSnapshot()
	fmt.Printf("HeapAlloc=%d HeapInuse=%d InuseSlack=%d\\n",
		snapshot.heapAlloc,
		snapshot.heapInuse,
		snapshot.inuseSlack) // 输出原始字节，单位换算交给展示层。
}

这里的 InuseSlack 不是 Go 官方新增字段，只是应用层为了观察方便计算出的差值。监控系统最好同时记录原始值和采样时间，避免只保存一个比值而丢掉 GC、流量和发布事件的上下文。

HeapAlloc 变大时，先区分对象增长和清扫时机

HeapAlloc 会随着堆对象分配增加，也会随着不可达对象被清扫而减少。但 Go 的清扫是增量进行的，所以它不一定每次都在 GC 结束的瞬间跳成一个整齐的锯齿形。短时间上涨只能说明当前对象分配或回收节奏发生变化，不能单独证明有泄漏。

我通常把观察拆成三段：

1. 在相同请求量或相同批处理阶段采集一段时间序列，看 HeapAlloc 是否在多个 GC 周期后仍抬高。
2. 把 HeapObjects、分配次数和业务队列长度放在同一时间轴，判断是对象数量持续增加，还是少数大对象占用变多。
3. 只在受控诊断实验里考虑手动 GC，生产监控不要把 runtime.GC() 当成常规修复动作；它会改变时序并带来额外开销。

func readAfterControlledGC() runtime.MemStats {
	runtime.GC() // 仅用于隔离实验中的对比，不应作为线上告警处理器。

	var stats runtime.MemStats
	runtime.ReadMemStats(&stats) // 在同一实验点读取回收后的快照。
	return stats
}

如果受控实验后 HeapAlloc 明显回落，之前的高点可能包含尚未清扫的不可达对象；如果它在稳定负载下跨多个周期持续增长，才更值得继续沿着引用链、缓存、队列和批量切片去找保留者。这个判断仍然需要 pprof 或业务对象证据，不能只凭一个 MemStats 字段定案。

HeapInuse 变大时，重点看 size class 空间

当 HeapInuse 上升而 HeapAlloc 增幅较小，常见解释是运行时为了容纳不同大小的对象启用了更多 in-use spans，span 中出现了尚未使用但仍可复用的容量。官方文档把 HeapInuse - HeapAlloc 定义为特定 size class 的未使用部分估计，因此它更像“分配槽位与对象之间的间隙”，不是独立的泄漏量。

这类差值在以下场景中可能自然变大：

• 短时突发分配把堆推到较高容量，业务峰值过去后，span 仍被运行时保留以便复用；
• 对象大小分布分散，某些 size class 的 span 只放入少量对象；
• 对象已经释放，但对应的 span 尚未转为空闲，或者还没有被运行时归还给操作系统。

所以我会把 HeapInuse 和差值画成趋势，而不是为差值设置一个脱离服务规模的“超过多少就是泄漏”阈值。若差值长期上升且业务负载没有相应变化，再结合分配热点和对象生命周期分析，才有诊断价值。

为什么还要同时看 HeapSys、HeapIdle 和 HeapReleased

只看两个字段，容易把“对象占用”“堆地址保留”“物理内存是否归还”混成一件事。Go 官方定义里，HeapSys 更接近运行时从操作系统取得的堆虚拟地址空间，可能包括尚未实际使用的保留空间；HeapIdle 是没有对象的 idle spans；HeapReleased 是已经归还给操作系统、且尚未重新取回的堆物理内存。

可以按下面的方向读数：

如果问题是容器被 OOM、进程 RSS 偏高或 cgo 分配增长，别停在这些堆字段上。MemStats 还包含栈、运行时内部结构等统计，但进程内存也可能来自映射文件、cgo 或其他非 Go 堆来源；这些要和操作系统指标、容器指标以及对应工具分开核对。

我会怎样把这组指标放进排障流程

我的做法是先保存五个原始字段：HeapAlloc、HeapInuse、HeapSys、HeapIdle、HeapReleased，再按时间顺序加上 GC 次数、请求量和批处理阶段。这样可以把一个“内存涨了”的模糊现象拆成几个更具体的问题：

1. 对象是不是没降下来：看多个 GC 周期后的 HeapAlloc 和 HeapObjects，再找引用保留者。
2. span 是不是比对象大很多：看 HeapInuse - HeapAlloc，并把它当作 size class 复用线索。
3. 堆是不是经历过峰值：看 HeapSys 与 HeapIdle，确认运行时是否保留了可复用空间。
4. 物理内存有没有回到 OS：看 HeapReleased，但最终 RSS 仍要用合适的进程/容器指标观察。

这种分层对我来说比盯着一个“内存总量”更有用：它能先告诉我问题发生在对象、分配槽位、堆保留还是堆外，再决定是否需要进入 pprof、代码引用链或操作系统层面。

常见疑问

HeapAlloc 一定等于所有存活对象的大小吗？不一定。它是已分配堆对象字节数，官方说明还包括 GC 尚未释放的不可达对象，所以采样时机很重要。

HeapInuse 比 HeapAlloc 大就是内存泄漏吗？不是。这是常见且合理的情况；差值反映 in-use span 中尚未被对象占用的容量上界，通常可被同类 size class 复用。

HeapSys 高是不是 RSS 高？不能直接等同。HeapSys 主要描述运行时为堆保留的虚拟地址空间，还可能包含尚未使用或已归还物理页的部分。

为什么 HeapAlloc 降了，进程内存看起来还没降？对象释放、span 变为空闲、物理页归还和操作系统回收不是同一个时间点；还要考虑栈、运行时内部结构、映射和 cgo 内存。

小结

HeapAlloc 和 HeapInuse 的核心差异，是“对象字节”与“in-use span 容量”的差异。把 HeapInuse - HeapAlloc 当作 size class 复用线索，再用 HeapSys、HeapIdle、HeapReleased 区分保留、闲置和归还，最后把堆内指标与 RSS、cgo 和业务对象证据拼起来，排查结果才不会被单个数字带偏。