Go sync.Pool 复用大 Buffer 后内存不降？从容量残留到回收节奏这样排查

图片处理接口刚扛完一波大文件请求，QPS 已经降下来，监控里的 RSS 却还停在高位。代码里明明每次都对 bytes.Buffer 调了 Reset()，还用了 sync.Pool，于是很容易把结论写成“对象池泄漏了”。这个判断常常太快：真正留下来的，往往是某次 8MB 请求撑大的底层数组，以及运行时尚未向操作系统归还的空闲页。

遇到这种内存居高不下的场景，不用上来就把 sync.Pool 直接删掉排查，先确认大 buffer 的底层容量有没有残留、Go 运行时的页回收节奏是否正常，绝大多数情况都不是真的对象泄漏。

问题现场：流量回落，内存为什么还在高位

下面是一个常见的 JSON 聚合服务写法。绝大多数响应只有几 KB，但偶尔会拼出数 MB 的导出内容。为了减少小对象分配，服务把 bytes.Buffer 放进池里。

var bufferPool = sync.Pool{
    New: func() any {
        return new(bytes.Buffer)
    },
}

func renderReport(rows [][]byte) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    defer func() {
        buf.Reset()
        bufferPool.Put(buf)
    }()

    for _, row := range rows {
        buf.Write(row)
        buf.WriteByte('\n')
    }
    return append([]byte(nil), buf.Bytes()...)
}

这段代码不会因为 Put 本身产生永久引用，但它会把曾经扩容过的 bytes.Buffer 继续留给后续请求复用。一次 8MB 导出结束后，下一次只写 2KB 的普通请求，拿到的仍可能是容量很大的 buffer。长度变小了，底层数组没有自动变小。

先别急着改成“不用对象池”。先记录一个高峰前后都能对比的指标组：HeapAlloc、HeapInuse、HeapIdle、HeapReleased、RSS，以及 allocation profile 里最大的分配栈。只看一个容器监控数字，很容易把正常的保留策略和真正的引用泄漏混在一起。

先做一个最小复现：Reset 以后容量还在

bytes.Buffer 的 Len() 和 Cap() 是两个不同的维度。下面的输出能把现象说清楚：Reset 后可读内容清空，但容量仍保持在大请求扩容后的级别。

func main() {
    var buf bytes.Buffer
    buf.Grow(8 

这正是复用的价值：下一次真有大响应时，不必再申请同样大的连续空间。但业务流量如果是“很少的大包 + 大量小包”，这个价值会反过来变成常驻内存成本。更关键的是，池里的项目随时可能被运行时移除，不能把它当作命中率可预测、容量可精确管理的缓存。

为什么一个大请求会影响后面的普通请求

把对象池想成“暂存可复用对象的篮子”更贴切，而不是“自动瘦身器”。请求 A 写入 8MB 后把 buffer 放回去，请求 B 写 4KB 时可能恰好取回它。B 的业务结果当然只有 4KB，可进程仍持有那块大数组。这不是并发错乱，也不是 Reset 失效。

还要留意一个看起来无害的细节：如果把 buf.Bytes() 直接交给异步队列、日志批处理器或全局切片，再立刻把 buffer 放回池，问题就不只是内存高了，还会有数据被后续请求改写的风险。对外返回或异步保存的数据，应当复制到自己的切片；对象池只回收不再被其他路径使用的工作缓冲。

修复方案：只归还适合复用的容量

最实用的做法通常不是禁用对象池，而是设一条容量边界。普通响应继续复用；超过阈值的 buffer 只做 Reset，不再放回池。阈值不要拍脑袋设成 8MB，可以先从正常响应 P99 的两到四倍开始，结合堆 profile 调整。

const maxPooledBuffer = 256  maxPooledBuffer {
        // 大数组不再交回池，函数返回后可被垃圾回收处理。
        return
    }
    buf.Reset()
    bufferPool.Put(buf)
}

func renderReport(rows [][]byte) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    defer putBuffer(buf)

    for _, row := range rows {
        buf.Write(row)
        buf.WriteByte('\n')
    }
    return append([]byte(nil), buf.Bytes()...)
}

这里有两个边界。第一，阈值保护的是对象池的复用对象，不会立刻让进程 RSS 掉到某个固定数值；运行时何时扫描、何时把空闲页交还给系统，仍有自己的节奏。第二，别为了追求曲线好看，在每个请求结束时调用 runtime.GC()。频繁强制 GC 会把 CPU 时间花在回收上，延迟也会更难看。只有在离线批处理完成、大对象生命周期非常明确的场景，才值得单独评估这种手段。

怎么确认回落是正常的，而不是把泄漏藏起来

修复后做两轮同样的压测：第一轮包含一个大响应，第二轮只跑普通响应。每轮结束后留出一段空闲时间，再抓一次 heap profile。重点看两件事：大 buffer 对应的分配栈是否持续增加；经过 GC 周期后 HeapInuse 是否回到稳定区间。若它能回落并在后续轮次保持平稳，通常说明是容量保留而不是持续泄漏。

func printMem(label string) {
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    fmt.Printf("%s alloc=%dMiB inuse=%dMiB idle=%dMiB released=%dMiB\n",
        label,
        m.HeapAlloc>>20,
        m.HeapInuse>>20,
        m.HeapIdle>>20,
        m.HeapReleased>>20,
    )
}

排查时我更建议把 profile 对比当成最后裁判：用 go tool pprof 对比高峰后两次 heap 快照，确认顶层保留者到底是 bytes.Buffer、业务缓存、请求队列还是日志批次。若只盯着 RSS，可能会错过真正被 map、全局切片或长生命周期 goroutine 持有的对象。

几个经常混淆的边界

• Pool 会不会保证复用？不会。取回 nil 是正常路径，New 只是补充新对象的工厂。
• 把 Pool 清空能否作为常规手段？不应依赖这种思路。对象池的内容由运行时管理，业务层应靠容量阈值控制哪些对象允许归还。
• Buffer 只要 Reset 就一定安全？只有没有任何其他引用继续读取它时才安全。异步路径必须使用独立的字节切片。
• 所有大对象都该放 Pool 吗？不该。复用收益要能覆盖常驻内存成本；偶发大对象更适合自然结束生命周期。

延伸问答

sync.Pool 会造成内存泄漏吗？

它本身的语义不是永久保存对象，池中项目可被运行时移除。真正需要排查的是对象是否被业务缓存、全局变量、队列或 goroutine 长时间引用，以及是否把大容量对象持续放回池。

bytes.Buffer 的 Reset 和 Truncate(0) 有什么区别？

两者都能让可读长度回到零，核心都不会承诺缩小底层容量。要限制大数组留存，应该在归还对象池前根据 Cap() 做取舍。

为什么 HeapAlloc 降了，容器内存还是很高？

HeapAlloc 描述当前存活对象占用，RSS 还会受到运行时保留空闲页、栈、代码段和其他映射影响。应结合 HeapInuse、HeapReleased、时间窗口和 profile 一起看。

对象池阈值该设多少？

从正常请求响应大小 P99 的两到四倍起步更可靠，再观察分配率和稳定期内存。阈值越大，分配压力可能越小，但留存大数组的概率也越高。

收尾：先区分容量留存，再决定是否动对象池

对象池后的内存曲线不立刻下降，并不能单独证明有泄漏。先用 Len、Cap 和 heap profile 确认大数组是否仍在池里；再通过容量阈值把偶发大 buffer 排除在复用路径外；最后用两轮压测验证稳定期是否回到同一范围。把这三步做完，既能保留小对象复用的收益，也不会让一次异常大的请求长期占着内存。