Go sync.Pool 复用 bytes.Buffer 为什么会串数据：Reset 位置和归还时机

线上接口偶尔返回上一位用户的 JSON 片段，不少人第一反应先查缓存配置。最后排查下来问题出在一个常见的性能优化操作：把 bytes.Buffer 放进 sync.Pool 复用。sync.Pool 本身不会自动帮你清空对象内容，也不可能感知到某个 goroutine 是不是还在读写这块内存。

先看现象：长度对了，内容却多了一截

最常见的错误是只往新 Buffer 里写内容，完全不处理旧数据。第二次拿到同一个对象时，写入会直接从旧内容的长度位置往后追加。日志里看到的不是随机乱码，而是上一次响应的尾部还在，这就是非常明确的串数据信号。

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

func badEncode(name string) string {
    buf := pool.Get().(*bytes.Buffer)
    defer pool.Put(buf)
    fmt.Fprintf(buf, `{"name":%q}`, name)
    return buf.String()
}

这种写法第一次运行大概率正常，后续复用同一个对象时，结果就会变成两段 JSON 粘在一起。pool.Get() 只表示拿到一个可复用对象，绝不代表它处于刚初始化的空白状态。

最小修复：借出后清空，完成后归还

把状态恢复放在借出之后最直观稳妥。无论对象此前被谁用过，当前函数拿到的都是一个长度为零的 Buffer；等当前逻辑所有读写操作完成之后再归还。输出响应时还要先把结果转成独立的字节切片存储，不能归还对象之后继续引用 Buffer 内部的底层数组。

func encode(name string) []byte {
    buf := pool.Get().(*bytes.Buffer)
    buf.Reset()
    defer pool.Put(buf)

    fmt.Fprintf(buf, `{"name":%q}`, name)
    out := append([]byte(nil), buf.Bytes()...)
    return out
}

更隐蔽的坑：异步写入时过早 Put

下面的模式也会串数据：函数启动一个 goroutine 写 Buffer，却在 goroutine 执行结束前就归还对象。另一个请求可能马上取到同一个对象并 Reset，前一个写入结果就会被直接覆盖。这里不用急着加锁，先把 Buffer 的所有权收归到同一个 goroutine 下，或者等异步写入完全完成后再执行 Put 操作。

如何验证修复是否有效

先让同一段编码逻辑连续运行几千次，检查每个结果都能独立正常解析。再用竞态检测工具跑并发用例；如果业务逻辑依赖异步写入，要让测试覆盖“写入尚未完成时有新请求借对象”的时序场景。

go test -race ./...
go test -run TestEncode -count=100

对象池不是内存正确性的兜底工具。它的作用只是减少短期分配开销；逻辑正确性仍依赖初始化、所有权和生命周期管控。没有明显分配热点时，直接创建全新 Buffer 通常代码可读性更高，也更难写错。

相关问题

Reset 会释放底层数组吗？

不会。它把缓冲区长度归零，底层容量通常会完整保留给后续复用，这也正是用池化能减少内存分配的核心原因。

能把 Buffer 指针返回给调用方吗？

可以，但调用方持有对象的整个期间不能执行 Put 操作。更简单稳妥的接口是返回独立的字节切片，对象所有权边界会更清晰。

sync.Pool 适合做全局缓存吗？

不适合。池中的对象可能在垃圾回收后被自动清除，也不保证访问时一定能命中；它的定位永远是服务于临时对象复用。

什么时候不该用对象池？

对象本身很小、调用频次不高或者生命周期跨多个异步阶段时，优先走普通分配逻辑，先做基准测试和性能剖析确认池化真的能带来收益再使用。