sync.Pool仅适用于高频分配、短生命周期的小对象（如[]byte、bytes.Buffer），禁用于大对象、带外部资源或有状态对象；New必须返回新实例，Get后需Reset，Put前须确保安全复用。
Sync.Pool 什么时候该用，什么时候不该用
绝大多数场景下，sync.Pool 不是“性能银弹”，而是为高频分配+短生命周期对象设计的缓存层。它只在你明确观测到 GC 压力来自某类小对象（比如 []byte、strings.Builder、自定义结构体）且分配频次极高（如 HTTP 中间件、序列化/反序列化循环）时才值得引入。
常见误用：把大对象（>1KB）、带外部资源（如未关闭的 io.Reader）、或有状态的对象丢进 sync.Pool —— 它不保证对象复用前被清空，也不做生命周期管理。
- 适合：HTTP 请求中反复创建的
bytes.Buffer、JSON 解析用的map[string]interface{}临时容器 - 不适合：数据库连接、文件句柄、含指针字段未重置的结构体（容易引发数据残留或 panic）
- 验证是否有效：对比使用前后
go tool pprof http://localhost:6060/debug/pprof/heap的 allocs/op 和 GC pause 时间
New 字段必须返回全新对象，不能复用旧实例
sync.Pool 的 New 字段不是初始化钩子，而是“兜底工厂”——当池为空时调用它生成新对象。很多人在这里写错，比如：
var bufPool = sync.Pool{
New: func() interface{} {
return &bytes.Buffer{} // ✅ 正确：每次返回新实例
},
}
错误写法是缓存一个全局变量再返回它，这会导致并发 panic：
立即学习“go语言免费学习笔记（深入）”；
var globalBuf bytes.Buffer
var badPool = sync.Pool{
New: func() interface{} {
return &globalBuf // ❌ 危险：多个 goroutine 同时读写同一实例
},
}
-
New函数必须无副作用、线程安全、且返回全新对象 - 如果对象需要预分配容量（如
make([]byte, 0, 1024)），必须在New里做，不能靠 Get 后手动扩容（否则失去复用意义） - 不要在
New里做耗时操作（如打开文件、网络请求），它可能在任意 goroutine 中被调用
Get 之后必须显式 Reset，Put 之前必须确保可安全复用
sync.Pool 不会自动清理对象状态。比如从池里拿到一个 bytes.Buffer，它内部的字节切片可能还残留上一次写入的内容，直接追加会导致脏数据；同理，结构体字段若没重置，可能携带过期逻辑状态。
典型修复模式：
buf := bufPool.Get().(*bytes.Buffer) buf.Reset() // ✅ 必须调用，清空内容和长度，但保留底层数组 // ... 使用 buf bufPool.Put(buf)
- 所有可复用类型都应实现
Reset()方法（标准库如bytes.Buffer、strings.Builder已提供） - 自定义结构体务必自己写
Reset()，把所有字段设回零值（注意指针字段要置nil，避免内存泄漏） - Put 前检查对象是否已被释放（如
io.Closer是否已 Close）、是否正被其他 goroutine 使用（需额外同步）
Pool 对象没有固定归属，GC 会不定期清理整个池
sync.Pool 是 per-P（goroutine 调度单元）局部缓存，不是全局单例。同一个 sync.Pool 实例在不同 P 上维护独立的本地池，跨 P 获取对象会触发迁移，带来开销；更关键的是，Go 运行时会在每次 GC 开始前清空所有池 —— 所以它本质是“弱引用缓存”，不能用于保存必须持久化的数据。
- 不要依赖
Get一定能拿到上次Put的对象，也不保证 Put 后对象一定被复用 - 高吞吐服务中，如果对象复用率长期低于 30%，说明池太小或使用模式不匹配，考虑调大初始容量或换用对象池管理器（如
go.uber.org/zap的bufferpool） - 测试时禁用 GC（
GODEBUG=gctrace=1）能直观看到池被清空的时机，方便判断复用效率
真正难的不是写对 sync.Pool 的 API 调用，而是判断某个对象是否真的“适合复用”：它得足够轻、生命周期足够短、状态足够干净、且分配频率高到 GC 都开始抱怨。漏掉其中任一环，池就从减压阀变成隐患源。
