Go sync.Pool 对象复用有哪些常见踩坑？

Question

仓乃文 · Accepted Answer

sync.Pool 是 Go 官方的临时对象复用机制，能减少堆分配和 GC 压力。但用错反而拖慢性能甚至引发 bug，以下是三个最常见的坑。

坑 1——Pool 对象被 GC 清空：
```go
// sync.Pool 在每次 GC 前会清空所有缓存对象
// 如果对象生命周期接近 GC 周期，Pool 几乎不起作用
var pool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}
buf := pool.Get().(*bytes.Buffer)
buf.Reset() // 必须 Reset，Pool 不保证对象是干净的
buf.Write(data)
use(buf)
pool.Put(buf) // GC 发生后，这个 buf 可能已被回收
```

坑 2——Put 前未重置导致脏数据：
```go
type Request struct {
    ID    int64
    Items []Item
}

func (r *Request) Reset() {
    r.ID = 0
    r.Items = r.Items[:0] // 清空但保留容量
}

// 每次使用前必须 Reset
r := pool.Get().(*Request)
r.Reset() // 不 Reset 的话，Items 里是上一次的数据！
```

坑 3——不该用 Pool 的场景用了 Pool：
```go
// 栈上分配的小对象，用 Pool 反而更慢
// Pool 的 Get/Put 有原子操作和类型断言开销
// 只有确定逃逸到堆 + 高频创建的对象才值得 Pool

// 含 Mutex 的对象放 Pool 要特别小心
// 必须在 Put 前确保 Mutex 已 Unlock
```

补充说明：
- Pool 是 per-P 本地缓存，跨 goroutine 复用效率低
- 不要 Pool 化长期存活的对象（如 DB 连接），那会阻碍 GC
- 验证 Pool 效果：go tool pprof -alloc_space 对比开启前后的分配量
- 规则：先确认逃逸（go build -gcflags="-m"），再上 Pool