sync.Pool 在对象构造成本低时反而更慢，因原子操作开销超过分配本身；仅当初始化耗时＞100ns且复用率高时才有优势。
为什么 sync.Pool 有时反而更慢？
不是所有高频创建场景都适合 sync.Pool。当对象构造成本极低（比如空 struct 或几个字段的 struct），而 Put/Get 的原子操作开销（内部用 atomic.LoadUint64、锁等）超过分配本身时，用池子反而拖慢性能。实测中，sync.Pool 在对象初始化耗时 >100ns 且复用率高（如每秒千次以上重复分配）时才显优势。
- 用
go test -bench=.对比new(MyStruct)和pool.Get().(*MyStruct)的基准数据，别凭感觉 - 注意 GC 压力变化：池中对象生命周期脱离 GC 控制，若长期不触发 GC，可能掩盖内存泄漏
- 避免在短生命周期 goroutine（如 HTTP handler）里 Put 大量对象——它们大概率来不及被复用就被本地 P 缓存清理掉了
如何正确实现 Pool 的 New 函数？
sync.Pool 的 New 字段不是“每次 Get 都调用”，而是仅在池为空且无可用对象时兜底调用。它必须返回**全新、干净、未被使用过的对象**；否则会引发数据污染。
var bufPool = &sync.Pool{
New: func() interface{} {
// ✅ 正确：每次返回新分配的 []byte，长度为 0，容量可预设
return make([]byte, 0, 512)
},
}
- ❌ 错误写法：
return &MyStruct{ID: atomic.AddInt64(&counter, 1)}—— ID 会累积，下次 Get 到的不是干净对象 - ❌ 错误写法：
return unsafe.Pointer(...)——New必须返回 Go 可追踪的堆对象，否则 GC 可能提前回收 - 若对象含指针或需归零字段（如切片底层数组、map、chan），应在
Put前手动清空，或在New中重置，不能依赖 GC
HTTP 中复用 bytes.Buffer 的典型陷阱
很多教程直接把 bytes.Buffer 放进 sync.Pool，但忽略其内部 buf 字段是可增长切片——多次 Put/Get 后，buf 容量可能膨胀到极大值却永不收缩，最终吃光内存。
var bufferPool = &sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func handler(w http.ResponseWriter, r *http.Request) {
b := bufferPool.Get().(*bytes.Buffer)
defer bufferPool.Put(b)
b.Reset() // ✅ 必须调用！否则残留上次内容 + 底层数组不会缩容
b.WriteString("hello")
w.Write(b.Bytes())
}
-
b.Reset()清空内容并把len=0，但不改变cap；若业务中 buffer 常写入超 1MB，又频繁复用，最终每个 buffer 的 cap 都卡在 1MB+ - 更稳妥做法：在
Put前判断b.Cap() > 64*1024，然后*b = bytes.Buffer{}强制丢弃底层数组 - 不要对
bytes.Buffer做类型断言后直接赋值字段（如b.buf = nil），它不是导出字段，行为未定义
Pool 对象泄漏的隐蔽信号
sync.Pool 不提供对象数量监控，泄漏往往表现为：应用 RSS 持续上涨但 heap profile 显示活跃对象不多，或者 pprof 查看 runtime.mallocgc 调用频次下降但内存不释放。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否在 defer 中 Put，但函数 panic 导致 defer 未执行（尤其嵌套 defer 或 recover 后忘记 Put）
- 注意 context cancel 场景：goroutine 被 cancel 后提前退出，忘了 Put 对象
- 用
runtime.ReadMemStats定期采样Mallocs和Frees差值，若差值稳定增长，说明有对象没被 Put 回池 - Pool 本身不跨 P 传递对象，若某 P 上 Get 极多但 Put 极少（比如 worker goroutine 分配后传给其他 P 处理），该 P 的私有池会不断 New，造成假性泄漏
