17370845950

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 调用频次下降但内存不释放。

• 检查是否在 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，造成假性泄漏