Go 内存持续增长但 heap profile 看不到对象怎么办

Go 服务的 RSS 一直上涨，但打开 heap profile 后，顶部对象并不大，这种现象并不矛盾。heap profile 默认关注最近一次 GC 后仍存活的堆对象；RSS 还可能包含空闲但尚未归还的堆、goroutine 栈、运行时元数据、cgo 或其他堆外分配。排查的关键不是继续放大同一张图，而是把“进程占了多少内存”和“哪些 Go 对象还活着”分开。

官方资料：https://pkg.go.dev/runtime/pprof、https://pkg.go.dev/runtime、https://pkg.go.dev/runtime/metrics

先用 MemStats 或 runtime/metrics 判断增长属于 HeapAlloc、堆保留空间、栈还是运行时总量，再用 heap 找存活对象、用 allocs 找累计分配。只有这几组信号同时指向对象，才优先按对象泄漏继续查。

先确认增长的是哪一层

先记录同一时间窗口内的 RSS 和 Go 运行时指标。HeapAlloc 更接近仍被对象占用的堆字节，HeapInuse 是正在使用的 span，二者差值可以提示大小级别的碎片或未充分利用的 span；HeapIdle - HeapReleased 则表示已经闲置、但运行时暂时保留的空间。它们上涨的含义不同，不能都叫“对象泄漏”。

可以先按下面的关系做粗分：

• RSS 上涨、HeapAlloc 也持续上涨：优先看 heap 的 inuse_space 和 inuse_objects。
• RSS 上涨、HeapAlloc 稳定，但 HeapIdle - HeapReleased 变大：可能是堆经历过峰值后保留了可复用空间。
• RSS 上涨、HeapAlloc 稳定，但 StackInuse 或 goroutine 数量上涨：转看 goroutine profile 和栈使用。
• Go runtime 指标变化不大而 RSS 继续上涨：把 cgo、mmap、第三方分配器和文件映射列入排查范围。

理解 heap profile 的观察窗口

runtime/pprof 的 heap profile 不是“进程所有内存的快照”。官方文档说明，它报告最近一次完成 GC 时的统计，并会省略更新的分配，以避免短时间垃圾让存活对象视图失真。因此，刚发生的高峰、尚未进入完整 GC 观察窗口的分配，以及已经回收的短命对象，都可能让 heap 看起来比 RSS 平静。

另一个容易混淆的点是 profile 的样本指标。默认的 inuse_space 看当前存活对象按大小的采样；alloc_space 看程序启动以来累计分配的字节，包含后来已经被 GC 回收的部分。前者适合问“现在谁还占着”，后者适合问“谁制造了大量分配”。如果 heap 的 inuse 很平，但 allocs 的累计分配集中在某个调用栈，问题更像分配 churn、缓存抖动或短命对象过多，而不是仍被引用的对象泄漏。

因此，不要只执行一次 top 就下结论。至少在相同负载下保存两个时间点，并分别比较 inuse_space、inuse_objects、alloc_space 和 alloc_objects。

把 heap、allocs 与运行时指标组合起来

在 HTTP pprof 已启用时，可以把两类 profile 直接交给 go tool pprof。下面的命令只展示分析入口，输出应以同一服务、同一采样窗口为准：

# 先看当前仍存活的对象，默认关注 inuse_space
go tool pprof -sample_index=inuse_space http://127.0.0.1:6060/debug/pprof/heap

# 再看累计分配，寻找制造大量短命对象的调用栈
go tool pprof -sample_index=alloc_space http://127.0.0.1:6060/debug/pprof/allocs

# 如果堆对象解释不了 RSS，再看 goroutine 的当前栈集合
go tool pprof http://127.0.0.1:6060/debug/pprof/goroutine

如果服务没有暴露 HTTP 端点，也可以在应用内写出 profile。采集前显式调用一次 GC 只适合诊断窗口，不应作为线上“修复内存”的常驻逻辑；它的作用是让这次 heap 观察更接近一个完成 GC 后的状态。

package main

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

func writeHeapProfile(path string) error {
	// 诊断采集时让 heap 反映一次完成 GC 后的存活对象。
	runtime.GC()

	f, err := os.Create(path)
	if err != nil {
		return err
	}
	defer f.Close() // 文件句柄必须在 profile 写完后释放。

	// heap profile 适合看当前仍被引用的堆对象。
	return pprof.Lookup("heap").WriteTo(f, 0)
}

除了 profile，还要把 HeapAlloc、HeapInuse、HeapIdle、HeapReleased、StackInuse 和 HeapObjects 按时间记录。较新的运行时还可以通过 runtime/metrics 查看 /memory/classes/heap/objects:bytes、/memory/classes/heap/released:bytes、/memory/classes/heap/stacks:bytes 与 /memory/classes/total:bytes，从而把对象、已归还物理页、栈和 Go 运行时映射总量拆开。

用最小采集接口收敛判断

工程上可以把每次采集整理为一行时间序列：rss、HeapAlloc、HeapInuse、HeapIdle-HeapReleased、StackInuse、HeapObjects 和 goroutine 数量。先看哪一列和 RSS 同步，再决定下一张 profile。这样比反复刷新 heap 更快，也能避免把 Go 保留内存误当成泄漏。

常见修复方向也应和证据对应：对象仍存活时查全局缓存、长生命周期容器、闭包引用和未释放队列；allocs 很高但 inuse 平稳时查批量大小、临时切片和编码转换；栈或 goroutine 上涨时查阻塞、退出路径和后台 worker；Go 指标稳定而 RSS 上涨时则检查 cgo、映射文件、外部库和容器内存统计口径。没有哪一张 profile 能替代这层分流。

相关问题

heap profile 为什么和进程 RSS 不相等？

两者统计边界不同。RSS 是进程当前驻留的物理页，heap profile 主要描述 Go 堆分配采样；栈、运行时保留空间、cgo 和映射内存可能不在 heap 的顶部对象中。

应该先看 heap 还是 allocs？

想找“现在谁还占着”先看 heap；想找“谁持续制造分配”看 allocs。两者一起比较，才能区分存活对象增长与短命对象 churn。