Golang怎么用sync.Pool缓存对象_Golang如何复用临时对象减少内存分配【技巧】-Golang-PHP中文网

sync.pool仅适用于高频创建、短生命周期、无状态或可重置的对象，如bytes.buffer；需显式重置、避免外部引用、禁止延迟put、new必须返回全新实例，否则易致panic或数据错乱。

golang怎么用sync.pool缓存对象_golang如何复用临时对象减少内存分配【技巧】

sync.Pool 的适用场景很窄，不是所有对象都适合放进去

它只对「高频创建 + 短生命周期 + 无状态或可重置」的对象有效。比如 bytes.Buffer、json.Decoder、自定义的解析上下文结构体。如果你塞进去的是带外部引用（如闭包、指针指向全局 map）、含未清零字段（比如切片底层数组没重置）或依赖初始化顺序的对象，取出来后行为不可控。

常见错误现象：panic: runtime error: makeslice: cap out of range 或数据错乱——本质是旧对象残留状态没清理干净。

每次从 Get() 拿到的对象必须显式重置，不能直接用
不要在 Put() 前修改对象的指针字段指向长期存活内存，否则造成内存泄漏
Pool 不保证对象一定被复用，GC 时会清空，也不能跨 goroutine 保证“刚 Put 就能 Get 到”

New 字段必须返回全新对象，且不能有副作用

sync.Pool 的 New 字段是兜底工厂函数，只在池空时调用。很多人在这里写成单例模式或共享初始化逻辑，结果多个 goroutine 并发 Get 时触发竞态。

正确做法是：每次调用都返回一个干净、独立、可立即使用的实例。

var bufPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer) // ✅ 每次都是新分配
    },
}

错误写法：return &sharedBuf 或 return buf.Reset(); return buf（因为 sharedBuf 是包级变量，多 goroutine 共用）。

Put 和 Get 的调用时机决定效果，延迟 Put 很危险

对象应该在确定不再使用后立刻 Put()，而不是等到函数结束或 defer。defer 容易掩盖生命周期问题：如果对象被意外逃逸到 goroutine 外部（比如传给 channel、赋值给全局变量），再 Put 就会导致后续 Get 拿到脏数据。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

典型反模式：

func parse(r io.Reader) []byte {
    b := bufPool.Get().(*bytes.Buffer)
    defer bufPool.Put(b) // ❌ 可能还没读完就被放回池了
    b.Reset()
    io.Copy(b, r)
    return b.Bytes()
}

应改为：

func parse(r io.Reader) []byte {
    b := bufPool.Get().(*bytes.Buffer)
    b.Reset()
    io.Copy(b, r)
    data := b.Bytes() // 拷贝出结果
    bufPool.Put(b) // ✅ 确认 b 不再需要才放回
    return data
}