sync.Pool能显著降低GC压力，但仅适用于高频分配、短生命周期、大小稳定的小对象；误用会导致内存滞留、GC频次上升及脏数据复用，Get后必须手动Reset，Put前须确保对象已脱离所有goroutine作用域。
sync.Pool 有用，但不是所有场景都适合；用错反而增加 GC 压力和内存占用。
为什么新对象频繁分配会触发 GC？
Go 的 GC 是基于三色标记的并发回收器，当堆上短期存活的小对象过多（比如每秒百万级 []byte 或 struct{}），GC 频率会上升，表现为 runtime.GC 调用变多、STW 时间波动、CPU 在 mark assist 上耗时增加。
关键点在于：sync.Pool 不是“自动内存池”，它只在 GC 前被清空，且对象生命周期不可控——Get() 可能返回 nil，Put() 不保证对象一定被复用。
- Pool 中的对象只在下一次 GC 前有效，不会跨 GC 周期保留
- Pool 按 P（逻辑处理器）分片，高并发下不同 goroutine 可能拿到不同本地池里的对象
- 如果
Put()的对象太大（如 > 32KB），会被直接丢弃，不进入 Pool
什么样的对象适合放进 sync.Pool？
必须同时满足：临时性、可重置、大小稳定、构造开销明显。典型例子是 JSON 解析用的 bytes.Buffer、HTTP 中间件的上下文容器、短生命周期的切片缓冲区。
反例：*http.Request、带指针字段未清零的 struct、含 sync.Mutex 未重置的对象——Put 前没重置会导致数据污染或 panic。
- 每次
Put()前必须手动重置状态，比如buf.Reset()、slice = slice[:0] - 避免放入含 finalizer 的对象，Pool 不会调用
runtime.SetFinalizer - 不要放指针指向外部大对象的结构体，否则会阻止外部对象被回收
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// 使用时：
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须！否则残留上次写入内容
buf.WriteString("hello")
_ = buf.String()
bufPool.Put(buf) // 放回前已清空
sync.Pool 的 New 函数什么时候执行？
New 只在 Get() 返回 nil 时调用，也就是池为空且无可用对象时。它不预热，也不并发保护——New 函数本身需是并发安全的（通常只是 new(T) 或字面量构造）。
- 如果
New里做了重量级操作（如打开文件、建连接），会拖慢首次Get()，且无法复用收益 - Pool 不保证
New调用次数，压测中可能看到 New 调用量远低于 Get，说明复用率高；反之则说明对象没被有效回收或 Put 太少 - 可通过 pprof 查看
sync.Pool.allocs和sync.Pool.frees指标判断复用效果
容易被忽略的坑：goroutine 泄漏 + 内存不释放
最隐蔽的问题是：把 long-lived 对象（比如某个 handler 里长期持有的 *bytes.Buffer）误放进 Pool。由于 Pool 按 P 缓存，而 runtime 会动态调整 P 数量，该对象可能卡在某个已销毁的 P 的本地池中，直到下次 GC 才被清理——造成“延迟泄漏”。
- 永远不要把全局唯一或生命周期与 goroutine 不一致的对象 Put 进 Pool
- 测试时用
GODEBUG=gctrace=1观察 GC 日志，对比开启/关闭 Pool 后的gc N @X.Xs X.X%: ...行中堆增长速率 - pprof heap profile 中若看到大量
sync.Pool相关的堆块，大概率是 Put 了不该放的东西
真正要降 GC，先确认对象是否高频创建、是否真的能复用；sync.Pool 是手术刀，不是创可贴。
