Go sync.Pool 为什么不能当缓存：GC 清空、对象复用与数据污染

Go 的 sync.Pool 适合暂存“现在不用、以后可能再用”的临时对象，但它不是缓存，也不是带持久性的对象仓库。池中的元素可能在下一次垃圾回收时被清空，因此把用户数据、配置、会话或必须保留的结果放进去，最终会得到难以复现的空值或数据丢失。

sync.Pool 为什么不是缓存

sync.Pool 的文档明确允许运行时在不通知调用方的情况下移除池中元素。下面的写法看起来像缓存，却没有任何命中保证：

var pool sync.Pool
pool.Put("temporary")

value := pool.Get()
// value 可能是 nil，不能把它当作必然存在的缓存项

即使没有显式触发垃圾回收，也不能把“刚刚 Put 进去”当成“下一次 Get 一定能拿到”。池的目的在于帮助复用临时对象，而不是保存业务状态。需要命中率、过期时间、容量和一致性的场景，应选择真正的缓存或数据库。

用 Reset 切断上一次请求的数据

最常见的 sync.Pool 对象是 bytes.Buffer。拿到对象后先清空，使用结束后再清空一次，能把“使用前状态”和“放回池状态”都固定下来：

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

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

    buf.WriteString("result:")
    buf.Write(input)
    return append([]byte(nil), buf.Bytes()...)
}

示例中的复制不能省略：buf.Bytes() 只是指向缓冲区底层数组的切片。函数把 buf 放回池后，下一次调用可能覆盖同一块内存；返回独立切片才能让结果脱离池的生命周期。

并发安全不等于业务对象安全

Pool 可以被多个 goroutine 并发调用，但它不会替对象内部的状态提供保护。一个对象从池里取出后，只能由当前调用方独占使用；若把它同时交给异步任务和当前函数，仍然会发生数据竞争。

func usePool() {
    buf := bufferPool.Get().(*bytes.Buffer)
    defer func() {
        buf.Reset()
        bufferPool.Put(buf)
    }()

    // buf 只在当前调用链中使用。
    // 若交给 goroutine，必须等 goroutine 完成后才能 Put。
    buf.WriteString("one request")
}

“池本身支持并发”只说明 Get 和 Put 的调用方式安全，不代表取出的 *bytes.Buffer 可以被并发写入，也不代表放回池后还能继续读取。

什么情况下值得使用对象池

是否使用应由基准测试决定。先比较直接分配、复用后的吞吐、分配次数和尾延迟，再确认池化没有让代码更难维护。为了少一次分配而引入过大的共享缓冲区，可能反而增加内存占用。

上线前的四个核对点

• 池中的对象是否纯粹是临时数据，不承载业务正确性。
• Get 后是否类型断言安全，New 是否覆盖空池返回的首次路径。
• Put 前是否 Reset，返回值是否已经复制出底层数组。
• 是否用基准测试证明池化收益，并检查大对象长期占用内存的风险。

常见问题

sync.Pool 里的对象什么时候会消失？

运行时可以在垃圾回收周期中清空池中的元素，调用方不能依赖元素跨 GC 保留。

Put 之前一定要 Reset 吗？

对带状态的缓冲区通常应该这样做，否则下一次调用可能读到上一次请求残留的数据。

从 Pool 取出的对象可以保存到全局变量吗？

不建议。对象的所有权应限定在当前使用阶段，放回池后继续持有并使用会造成生命周期和并发边界混乱。

用了 sync.Pool 就一定更快吗？

不一定。只有基准测试显示分配和 GC 压力是实际瓶颈时，池化才值得引入。