内存曲线不断上涨是泄漏还是缓存，怎样用对象持有链区分

先说判断标准：缓存和泄漏在 Go 垃圾回收器看来没有本质区别，它们都是从某个根引用仍然可达的对象。区别来自业务生命周期：缓存有明确的容量、TTL、淘汰或清空边界，稳定负载下会进入平台；泄漏则是退出路径缺失，隐藏的 map、goroutine、channel、timer 或闭包继续持有对象，导致同一持有者的对象数和 live heap 长期增长。

因此不能只看内存曲线，也不能只看一次 pprof。正确做法是：先用 heap profile 找到持续增长对象的分配栈，再沿代码和指标还原“根引用 → 持有者 → 业务对象 → 大字段”的持有链，最后执行清空、过期、取消或排空实验，确认这条链是否会按设计断开。

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

用户任务：先判断曲线为什么涨

看到内存持续上涨时，先把“涨”拆成三个可验证问题：

1. Go live heap 是否增长：观察 inuse_space，不要把进程 RSS 直接等同于 Go 堆。
2. 哪个分配栈增长：比较相近负载、相同版本、GC 后的多张 heap profile。
3. 谁让对象继续可达：从分配点回到 owner 容器，检查它的加入、删除、过期和退出路径。

Go 官方的 runtime/pprof 文档说明，heap profile 跟踪的是存活对象和历史对象的分配位置。它擅长回答“对象从哪里分配”，但普通 pprof 报告不会直接画出“现在是谁引用它”的完整对象图。把调用图当作持有链，是内存排查中最常见的误区之一。

交互拆解：把诊断动作拆成一条持有链

一条实用的持有链至少包含四类角色：

例如 pprof 显示 decodePayload 分配的 []byte 在增长，这只告诉你分配入口。真正的持有链可能是 package 全局变量 → sessions map → *Session → Payload []byte，也可能是 goroutine 栈 → worker 闭包 → *Session → Payload []byte。修复点通常在 owner 的退出路径，而不是分配函数本身。

组件实现：让缓存拥有明确的释放边界

真正的缓存不能只提供 Put 和 Get，还要定义容量、过期、删除和可观察统计。下面是一个用于说明生命周期的简化实现。它采用线性扫描淘汰最早条目，适合教学；高并发生产代码可换成成熟缓存库或更合适的数据结构，但释放契约应保持一致。

package ownercache

import (
	"sync"
	"time"
)

type entry struct {
	value     []byte
	createdAt time.Time
	expiresAt time.Time
}

type Stats struct {
	Entries  int
	Bytes    int64
	Evicted  uint64
	Expired  uint64
}

type Cache struct {
	mu      sync.Mutex
	items   map[string]entry
	max     int
	bytes   int64
	evicted uint64
	expired uint64
}

func New(maxEntries int) *Cache {
	// 容量必须大于零，避免出现没有上限的伪缓存
	if maxEntries = c.max {
		c.evictOldestLocked()
	}

	now := time.Now()
	c.items[key] = entry{
		value:     value,
		createdAt: now,
		expiresAt: now.Add(ttl),
	}
	c.bytes += int64(len(value))
}

func (c *Cache) Delete(key string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.deleteLocked(key)
}

func (c *Cache) Sweep(now time.Time) {
	c.mu.Lock()
	defer c.mu.Unlock()

	// 过期扫描必须真实删除 map 项，不能只标记为失效
	for key, item := range c.items {
		if !item.expiresAt.After(now) {
			c.bytes -= int64(len(item.value))
			delete(c.items, key)
			c.expired++
		}
	}
}

func (c *Cache) Snapshot() Stats {
	c.mu.Lock()
	defer c.mu.Unlock()

	// 返回 owner 维度指标，便于和 live heap 同时观察
	return Stats{
		Entries: len(c.items),
		Bytes:   c.bytes,
		Evicted: c.evicted,
		Expired: c.expired,
	}
}

func (c *Cache) deleteLocked(key string) {
	if item, ok := c.items[key]; ok {
		c.bytes -= int64(len(item.value))
		delete(c.items, key)
	}
}

func (c *Cache) evictOldestLocked() {
	var oldestKey string
	var oldestTime time.Time
	for key, item := range c.items {
		if oldestKey == "" || item.createdAt.Before(oldestTime) {
			oldestKey = key
			oldestTime = item.createdAt
		}
	}
	if oldestKey != "" {
		c.deleteLocked(oldestKey)
		c.evicted++
	}
}

这段代码的重点不是淘汰算法，而是 owner 有明确边界：max 限制条目数，Sweep 断开过期引用，Delete 支持业务主动释放，Snapshot 暴露 owner 的条目数和 payload 字节数。只要这四项缺一，就很难仅凭 pprof 证明它是“合理缓存”。

可观察性：让持有者信息可读

对象持有链需要业务指标来补足 pprof 的语义。建议每个长期 owner 至少提供以下信息：

指标名要表达“谁在持有”，标签基数要受控。不要把用户 ID、请求 ID 或缓存 key 直接做成监控标签，否则为了排查内存反而制造新的高基数内存问题。

性能检查：用释放实验验证业务意图

缓存与泄漏最有说服力的差别，是预期释放动作是否有效。先在稳定负载下采集 GC 后的基线快照，再执行一个业务允许的释放动作，例如清空测试租户缓存、等待 TTL、取消任务、关闭订阅或排空队列，最后再次触发 GC 并采集快照。

# 稳定负载下触发 GC，保存释放动作前的 live heap
curl -fsS 'http://127.0.0.1:6060/debug/pprof/heap?gc=1' \
  -o before-release.pb.gz

# 在测试环境执行缓存清空、TTL 等待、cancel 或队列排空后再次采集
curl -fsS 'http://127.0.0.1:6060/debug/pprof/heap?gc=1' \
  -o after-release.pb.gz

# 负值表示释放后该分配栈的存活字节减少
go tool pprof \
  -sample_index=inuse_space \
  -diff_base=before-release.pb.gz \
  -top -nodecount=30 \
  after-release.pb.gz

# 对象数视图用于确认大量小对象是否真正退出持有链
go tool pprof \
  -sample_index=inuse_objects \
  -diff_base=before-release.pb.gz \
  -top -nodecount=30 \
  after-release.pb.gz

如果 cache_entries、cache_bytes 和对应分配栈的 inuse_space 一起下降，说明释放边界真实存在；如果 owner 指标声称已清空，但 live heap 对应栈仍不下降，就要继续寻找第二条持有链，例如 worker 闭包、重试队列或订阅表。

怎样从增长分配栈回到真正 owner

pprof 的 top 找增长栈，top -cum 和 list 用来定位创建对象的业务路径。随后按下面顺序阅读代码：

1. 查返回值被写入哪个 map、slice、channel、struct 字段或闭包变量；
2. 查这个容器自身由全局变量、server、tenant、worker 还是 goroutine 栈持有；
3. 查所有加入路径是否都有对应删除路径；
4. 查错误、超时、重试、panic 恢复和客户端断开时是否也会执行退出动作；
5. 查 timer、ticker、context cancel 和 goroutine 是否在业务结束后停止；
6. 把 owner 条目数与 pprof 的存活对象数放在同一时间窗口对照。

特别注意 slice：把长度缩短并不一定释放底层数组，如果旧元素仍留在底层数组且数组本身继续可达，指针字段仍可能保留对象。队列消费后应把不再使用的元素位置清零；大 slice 若只保留很小一段，必要时复制到新的小数组，避免小视图持有大底层数组。

边界状态：pprof 何时不够用

pprof 看到分配栈，看不到完整持有边

heap profile 是采样剖析，重点是分配位置和存活量，不是完整对象图。即使调用图中出现 A 调用 B，也不表示 A 现在持有 B 创建的对象。持有关系必须回到字段、容器和 goroutine 生命周期确认。

需要完整对象与根信息时谨慎使用 heap dump

runtime/debug.WriteHeapDump 能写出堆对象、goroutine、finalizer 等更完整的快照，可供兼容工具做进一步对象图分析。但官方明确说明，写 dump 期间会暂停所有 goroutine，直到文件完全写完。它不适合随意在高流量生产实例执行，应优先在可复现环境、隔离副本或明确维护窗口使用，并确保磁盘空间足够。

RSS 上涨但 Go 堆稳定

这时问题可能来自 goroutine 栈、runtime 元数据、mmap、cgo 或尚未归还给操作系统的空闲页。继续追 Go 对象持有链可能没有结果，应对照 runtime/metrics 的内存分类和进程级指标缩小范围。

缓存本来就允许增长到上限

缓存从冷启动到热态上涨并不等于泄漏。只要 key 空间、容量和 TTL 可解释，命中收益存在，淘汰动作工作，稳定负载下能达到平台，并能通过清空实验回落，它就是受控持有。反过来，名字叫 Cache 也不能自动证明合理。

快速判断表

常见问题

GC 后对象还在，就一定是泄漏吗？

不一定。只要对象仍被缓存、队列或活跃请求合法引用，它就应该存活。关键是持有者是否符合设计边界，以及释放动作能否让它退出可达集合。

pprof 的调用图能当对象引用图吗？

不能。调用图表达分配样本的调用路径，不等于当前堆对象之间的引用关系。它用来找分配入口，持有链要通过代码字段、容器和生命周期证据补全。

为什么清空 map 后内存曲线没有立刻下降？

可能尚未完成 GC，也可能仍有第二个 owner，或者 Go runtime 暂时保留已空闲的页而没有立即归还操作系统。先看 GC 后的 inuse_space 是否下降，再决定是否继续追 RSS。

怎样优先检查 goroutine 持有？

对照 goroutine profile、活跃 worker 数、context 取消路径和 channel 深度。未退出 goroutine 的栈、闭包变量或阻塞发送都可能让本应结束的请求对象继续可达。

总结

缓存和泄漏都表现为“对象仍可达”，所以名字、曲线和单次 pprof 都不能替业务意图作证。先用 heap profile 找持续增长的分配栈，再沿根引用、持有者、业务对象和大字段还原持有链，最后用容量、TTL、删除、取消和清空实验验证释放边界。

能解释、有限制、有收益、会淘汰、可回落的是受控缓存；退出路径缺失、隐藏根不断增加、稳定负载下没有平台、释放实验仍不下降的，才应按泄漏继续修复。