sync.Pool 通过复用临时对象减少堆内存分配，适用于高并发下短生命周期对象的场景，但需注意 GC 会清空池内对象且不可用于持久化存储。
先说结论：sync.Pool 仅在对象创建开销大、生命周期短且状态可安全重置时才能降低 allocs/op，误用反而增加 GC 压力。
- 先定位：使用 pprof 确认内存分配热点是否在频繁创建的对象上
- 先做：确保对象取出后手动 Reset 状态，使用后严格 Put 回池
- 再验证：通过 go test -bench 对比启用前后的 allocs/op 指标
命令速用版
var bufPool = sync.Pool{
New: func() interface{} {
return &bytes.Buffer{}
},
}
func handler() {
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)
buf.Reset() // 必须重置，避免脏数据
// 使用 buf...
}为什么会这样
高频分配临时对象会导致垃圾回收器频繁扫描堆内存，增加 CPU 开销。
Go 的垃圾回收器采用并发三色标记算法，虽然单次 STW 时间短，但在对象分配频率极高的场景下，GC 的累计开销会成为性能瓶颈。sync.Pool 允许对象在 GC 间被复用，避免重复分配和回收，但池中的对象会在每轮 GC 时被清空，因此它只能作为临时缓存而非持久存储。
分步处理
第一步：定义全局 Pool 变量。
在包级别定义 sync.Pool 实例，确保多个 Goroutine 共享同一个池。New 函数仅在池为空时调用，不能包含耗时操作或副作用。
第二步：获取对象后立即重置状态。
从 Get 方法拿到的对象可能是复用的旧对象，底层数组可能残留上一次写入的数据。对于 bytes.Buffer 类型，必须调用 Reset 方法清空长度，保留底层容量。
第三步：使用 defer 确保对象归还。
在函数退出前必须调用 Put 方法归还对象。推荐将 Put 放在 defer 中，防止因 panic 或提前返回导致对象泄露。确保 Put 前对象不再被其他 Goroutine 引用。
第四步：清理外部引用。
如果对象包含指针字段（如 http.Request），Put 前必须显式置 nil，防止指针滞留阻止关联内存被 GC 回收。
怎么验证是否生效
使用基准测试对比分配次数，而非仅看吞吐量。
运行 go test -bench . -benchmem 命令，观察 allocs/op 和 B/op 指标。如果 allocs 没有下降甚至上升，说明对象太小或复用率低，pool 的锁和接口转换开销超过了分配成本。结合 go tool pprof 查看 runtime.mallocgc 和 sync.(*Pool).Get 的调用频次与耗时占比，确认没有引入新的锁争用。
常见坑
对象太小反而更慢。
只有几个 int 字段的 struct 直接用内存分配器更快，pool 的维护成本高于分配成本。
误以为池是全局缓存。
sync.Pool 不保证对象存活时间，GC 发生时池会被清空，不能依赖它记住上次计算结果。
归还时机不对导致内存泄漏。
在 Goroutine 结束前没 Put，导致对象永远留在池里，既浪费内存又干扰 GC 判断。
脏数据污染。
复用 bytes.Buffer 时未调用 Reset，导致写入操作变成追加而非覆盖，响应体错乱。
常见问题
sync.Pool 能保证对象一定被复用吗？
不能保证，GC 发生时池内对象会被清空，且 Get 可能返回 New 创建的新对象。
什么场景不适合用 sync.Pool？
长生命周期对象、带外部资源的对象（如数据库连接）或小对象频繁创建场景不适合。
New 函数里可以做耗时操作吗？
不可以，New 可能在任意 Goroutine 中被触发，耗时操作会阻塞 Get 路径并引发竞态。
为什么用了 pool 反而 CPU 升高？
可能是多个 P 高频争抢同一个 pool 实例导致锁争用，或对象存活时间过长拖慢 GC 标记阶段。
参考来源
- Go 语言的 sync.Pool 对象池在高并发场景下的内存复用策略
- 如何在 Go 中利用 sync.Pool 减少频繁申请内存的压力
- sync.Pool 内存复用与性能优化:Go 高并发场景下的 GC 减负之道
- 如何在 Go 中利用 sync.Pool 减少高频业务下的堆内存申请压力
- Golang sync/pool 对象池与内存优化实践