Go 服务内存不降的堆引用排查方案

Go 服务处理完一批请求后，内存曲线没有立刻下降，先不要把它当成 GC 失效。更常见的原因是仍有对象可达：一个很小的切片还指向大块 backing array，缓存仍保存着切片或对象，或者 GC 已经回收对象，但运行时暂时保留了堆页。排查时要把“活跃对象”“堆占用”和“进程 RSS”分开看。

先分清“对象还活着”和“内存还没还给系统”

一次请求结束，只能说明请求函数返回了，不能说明请求期间创建的对象都不可达。如果全局变量、缓存、闭包或长生命周期结构仍保存着切片或对象，GC 必须保留它们。相反，活跃对象已经下降时，Go runtime 仍可能保留部分堆页供后续分配使用，所以 RSS 不会按请求结束的时间点立刻回落。

因此第一步不要直接看 RSS 下结论，而是同时记录最近一次 GC 后的 live heap、仍占据堆空间的对象、已经释放但尚未归还的堆页，以及自动 GC 周期。下面这张图只表达引用和内存层级，是静态说明图，不是运行截图。

切片变短了，底层大数组可能还在

切片只是指向数组的一段视图。下面的写法把大输入切成很短的结果，但 small 仍然和 input 共享 backing array；只要 small 被缓存，整块数组就可能继续存活。

func keepPreview(input []byte) []byte {
	// 这里只改变视图长度，返回值仍然引用 input 的大 backing array。
	return input[:min(len(input), 256)]
}

func keepIndependentPreview(input []byte) []byte {
	limit := min(len(input), 256)
	// 复制到新数组，让缓存只保留需要展示的短内容。
	preview := make([]byte, limit)
	copy(preview, input[:limit])
	return preview
}

slices.Clip 只能把容量上限裁到当前长度，它不会把数据复制到新的 backing array；如果原数组远大于结果，想真正断开大数组引用，应使用 slices.Clone 或上面的显式复制。修复后还要确认旧切片没有被其他字段、队列或缓存继续保存。

缓存清理要看 value 的引用，而不是只看 key 数量

缓存最容易制造“请求都结束了但堆还在涨”的错觉。一个 key 被淘汰，才会解除这个 value 从缓存 map 出发的引用；如果 value 又被另一个索引、待处理队列或统计快照保存，GC 仍然不能回收它。即使 value 已经不可达，map 自身的桶空间也不会因为一次 delete 就让进程 RSS 立即下降。

type PreviewCache struct {
	items map[string][]byte
}

func (c *PreviewCache) Remove(key string) {
	// delete 解除 key 到 value 的引用，调用方仍要检查是否有其他持有者。
	delete(c.items, key)
}

func (c *PreviewCache) Replace(next map[string][]byte) {
	// 批量重建时切换到新 map，避免长期保留不再需要的缓存条目。
	c.items = next
}

排查缓存时可以按这张速查表记录证据：

用 runtime/metrics 把判断落到同一组指标

runtime/metrics 提供以名称访问的运行时指标。对这个问题，至少应把最近一次 GC 后的活跃堆、堆对象占用、已归还堆页和自动 GC 周期放在同一时间窗口里；指标名称和数值类型要按官方描述处理，不能把所有值都当成普通整数。

package main

import (
	"fmt"
	"runtime/metrics"
)

func readMemorySignals() {
	samples := []metrics.Sample{
		{Name: "/gc/heap/live:bytes"},
		{Name: "/memory/classes/heap/objects:bytes"},
		{Name: "/memory/classes/heap/released:bytes"},
		{Name: "/gc/cycles/automatic:gc-cycles"},
	}
	// 一次读取同一批指标，避免用不同采样时刻拼出错误结论。
	metrics.Read(samples)
	for _, sample := range samples {
		// 这些示例指标都是 Uint64；生产采集仍应按 Kind 判断后再解码。
		if sample.Value.Kind() == metrics.KindUint64 {
			fmt.Printf("%s = %d\n", sample.Name, sample.Value.Uint64())
		}
	}
}

如果 /gc/heap/live:bytes 连续多个周期上升，优先找仍可达的切片或缓存 value；如果 live heap 已下降而 /memory/classes/heap/released:bytes 暂时不变，先按运行时复用堆页解释；如果自动 GC 周期快速增加且 live heap 仍接近高位，说明分配压力或缓存保留量仍然存在。指标是定位线索，不是替代引用分析的“泄漏开关”。

排查顺序和容易误判的地方

建议按“引用是否存在、切片是否保留大数组、缓存是否有清理、指标是否同窗采样”的顺序处理。不要一上来在业务请求中调用 runtime.GC()：它只能改变回收时机，不能解除仍然存在的引用；如果根因是缓存或切片生命周期，强制 GC 只会增加暂停和 CPU 成本。

修复后固定一组相近负载，比较多个 GC 周期的 live heap、heap objects、released memory 和 automatic cycles。只有当活跃堆下降、缓存引用解除且趋势稳定时，才算找到有效修复；RSS 是否马上回到峰值前，应该作为运行时行为另行观察。

常见问题

slices.Clip 用了以后，为什么内存还是不降？

它会把容量限制到长度，但不会复制底层数组。若短切片仍保留大 backing array，使用 slices.Clone 或显式复制建立独立副本。

删除缓存 key 后，RSS 为什么还在高位？

先区分 value 是否已经不可达，再看堆页是否已归还。map 桶和运行时保留页都可能让 RSS 延后下降，这不等同于仍有同样多的活跃对象。