sync.Pool 复用对象能减 GC？最佳实践你跟上没？

在 Go 语言高并发场景下，GC（垃圾回收）频繁触发导致的性能波动始终是开发者心头的一根刺。当每秒处理数万个请求时，短生命周期对象反复创建销毁的操作，不仅让内存分配器不堪重负，更会让 GC 线程在标记-清除循环中消耗大量 CPU。此时sync.Pool的价值便凸显出来——通过对象复用机制，它能让临时缓冲区、解析器实例等高频创建对象实现”循环再生”。

通过维护一个无锁对象池，sync.Pool 允许并发安全地存取临时对象。当调用 Get() 方法时：

buffer := pool.Get().(bytes.Buffer)
defer pool.Put(buffer)

优先获取已缓存对象而非新建实例，这使得内存分配次数下降 80% 以上。更重要的是，被复用的对象不会被 GC 判定为垃圾，自然避免了相关扫描和回收开销。

场景	对象分配次数/秒	GC 暂停时间
未使用 Pool	120,000	300ms/分钟
使用 Pool	22,000	45ms/分钟

必须指定New 函数来创建备用对象：

var bufferPool = &sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

否则当池中没有可用对象时，Get() 会直接返回 nil 导致 panic。

及时 Put 对象：通过 defer 确保对象归还
重置对象状态：buffer.Reset() 避免残留数据污染
池中不存大对象：超过 1MB 的对象建议直接释放

// 使用独立池避免锁竞争
var pools = [4]sync.Pool{}

func GetByShard() Buffer {
    return pools[rand.Intn(4)].Get().(Buffer)
}

通过分片池策略可降低 75% 的锁争用，在 32 核服务器上吞吐量提升 3 倍。

在 Gin 框架中，每次请求都会创建 context 对象。某电商平台通过 sync.Pool 复用 context 后，GC 时间从 1.2s/分钟降至 0.3s/分钟。

var jsonPool sync.Pool

func Marshal(v interface{}) ([]byte, error) {
    enc := jsonPool.Get().(json.Encoder)
    defer jsonPool.Put(enc)
    
    enc.Reset()
    return enc.Encode(v)
}