sync.pool适合高频创建、短生命周期、结构稳定的对象，如bytes.buffer、json解析临时对象；不适用于跨goroutine长期持有或需自动清理的场景。
sync.Pool 适合哪些场景
它不是万能缓存，只适合「高频创建 + 短生命周期 + 结构稳定」的对象。比如 HTTP 中间件里反复分配的 bytes.Buffer、JSON 解析用的 sync.Map 临时包装器、或自定义的请求上下文结构体。如果你的对象会跨 goroutine 长期持有，或者每次 New 出来后要塞进 map/chan 里长期存活，sync.Pool 不但不省内存，还会让 GC 更难回收——因为 Pool 内部引用会让对象在 GC 周期里“假装还活着”。
常见错误现象：sync.Pool.Get() 返回 nil 或脏数据；压测时内存不降反升；对象字段值“残留”上一次使用痕迹。
- Pool 不保证 Get 一定返回非 nil，必须做空值检查并 fallback 到
&MyStruct{} - Put 进去的对象不能被外部变量继续引用，否则可能被重复 Put 或导致竞态
- Pool 没有清理逻辑，不会调用对象的 Close/Reset 方法，得自己手动重置字段
如何正确初始化和重置对象
关键是把“构造”和“复用”逻辑拆开：New 函数只负责首次创建，Get 后必须显式 Reset。别指望 Go 自动清零字段——struct 字段不会自动归零，尤其是指针、map、slice 类型。
示例中容易踩的坑是直接 return &MyObj{} 而不重置，或在 Reset 里漏掉嵌套字段：
立即学习“go语言免费学习笔记（深入）”；
var objPool = sync.Pool{
New: func() interface{} {
return &MyObj{}
},
}
func (o *MyObj) Reset() {
o.ID = 0
o.Data = nil // 必须清空 slice 底层数组引用
if o.Cache != nil {
*o.Cache = map[string]int{} // 而不是 o.Cache = map[string]int{}
}
}
- Reset 必须是值接收者或指针接收者一致，且所有可变字段都要覆盖
- 不要在 Reset 里 new 新对象赋给字段（如
o.Slice = make([]byte, 0)），这会逃逸到堆，抵消 Pool 效果 - 如果结构体含
sync.Mutex，不能 Reset，也不能 Put 已 Lock 的对象
sync.Pool 在 GC 周期中的行为
每次 GC 开始前，Pool 会清空所有私有副本（per-P），并把共享池里的对象全部丢弃。这意味着：对象最多活过一次 GC 周期，无法用于跨请求状态传递；高并发下不同 P 的 Pool 实例互不通信，所以 Get 可能频繁 miss。
性能影响很实际：如果对象太大（比如 > 2KB），放进 Pool 反而增加 GC 扫描压力；如果 New 成本极低（如 &struct{}{}），用 Pool 可能纯属负优化。
- 用
runtime.ReadMemStats对比开启/关闭 Pool 时的Mallocs和HeapAlloc变化 - 避免把大 buffer（如 64KB
[]byte）直接丢进 Pool，改用固定大小的 ring buffer 或预分配切片池 - 不要依赖 Pool 的“保活”能力——它不保活，只图少 New
替代方案比 Pool 更合适的情况
当你的对象创建成本不高、或生命周期不可控时，直接 New 更安全。Go 1.22+ 的逃逸分析已经足够聪明，小对象常驻栈上，根本不会触发堆分配。
真正需要 Pool 的信号是 pprof 显示某类 struct 分配占比高 + 其中大量对象存活时间远小于 GC 周期。否则，优先考虑：
- 复用参数传入的 buffer（如
json.Unmarshal(data, &v)中的&v） - 用
strings.Builder替代频繁拼接的string+bytes.Buffer - 对 map/slice 做容量预估 +
make(T, 0, cap)，避免扩容抖动
Pool 是手术刀，不是创可贴。用错地方，比不用还容易埋坑。最常被忽略的一点：你写的 Reset 函数，是否真的覆盖了所有可能被修改的字段？尤其当结构体后续加了新字段，却忘了更新 Reset。
