sync.Pool只适合生命周期短、创建开销大、可安全重置的临时对象，如bytes.Buffer、http.Header、JSON解析器中的结构体；不适合含外部资源、不可重置状态或构造开销小的对象。
sync.Pool 适合什么场景？
它只适合生命周期明确、可复用的临时对象，比如 JSON 解析时的 bytes.Buffer、HTTP 中的 http.Header 或自定义结构体切片。不适合持有长生命周期引用（如全局 map）、含 finalizer 的对象，或需要强一致性的状态对象——sync.Pool 不保证 Get 一定返回旧对象，也可能返回 nil。
高频函数中反复 new 结构体或切片是典型适用点，比如日志序列化、协议编解码、中间件中的上下文载体。但注意：如果对象构造成本低（如空 struct），或调用频次不高（QPS sync.Pool 反而增加调度开销。
怎么写一个安全可用的 Pool 实例？
关键在 New 函数和对象重置逻辑。Pool 不会自动清空字段，必须手动归零或重置：
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func parseRequest(data []byte) []byte {
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须！否则残留上次数据
buf.Write(data)
result := buf.Bytes()
bufPool.Put(buf) // 归还前确保无外部引用
return result
}
常见错误：
- 忘记调用
Reset()或清空字段，导致脏数据泄露 - Put 前把 buf 地址传给 goroutine 异步使用，造成 use-after-free
-
New返回指针但 Get 后类型断言写错，panic - Pool 实例声明为局部变量，每次调用都新建 Pool，完全失效
为什么有时候 Put 了对象却没被复用？
sync.Pool 的本地缓存按 P（processor）隔离，每个 P 维护自己的私有池。当某个 P 长时间没调用 Get，其私有池会被 GC 清理；同时，Pool 在每次 GC 时也会清空所有私有池——所以「刚 Put 就 Get 不到」是正常行为，不是 bug。
这意味着：
- 不能依赖「Put 后下次 Get 一定命中」，始终要兼容
New创建路径 - 高并发下不同 goroutine 跑在不同 P 上，复用率取决于负载均衡程度
- 如果业务有明显波峰波谷，低峰期 Pool 缓存基本清空，复用率下降
性能对比和上线前必须验证的点 别只看基准测试数字。真实收益受 GC 压力、对象大小、分配频率影响极大。实测建议：
用 go tool pprof 对比开启前后：
立即学习“go语言免费学习笔记（深入）”；
-
runtime.MemStats.AllocBytes是否下降 -
gc pause时间是否缩短（尤其关注 99% 分位） - 观察
sync.Pool的命中率：go tool trace里看sync.Pool allocs和sync.Pool gets比值
最容易被忽略的是：Pool 对象若包含指针字段（比如切片、map、*string），且未在 Reset() 中清理，会导致本该回收的对象被意外保留，反而增加堆压力。这点在线上压测时才暴露得最清楚。
