sync.Pool中对象最多存活至下下一次GC，但可能被当前GC立即回收；Get()常获脏数据因无自动重置，需手动清理字段；命中率低主因是跨P调度导致本地缓存失效。
sync.Pool 里对象的存活时间不由你控制，只由 GC 的节奏和运行时调度决定；它不是缓存，也不是对象生命周期管理器，而是一个“尽力复用 + 定期清退”的临时暂存点。
sync.Pool 对象最多活到哪次 GC？
Go 1.13+ 引入 victim cache 机制后，一个对象 Put() 进 Pool 后：
- 第一次 GC 不会直接删，而是移到
victim缓存中 - 第二次 GC 才真正丢弃（即“下下一次 GC”前必死）
- 但具体在哪次 GC 被清理，完全不可预测——可能刚 Put 就被当前 GC 清掉（如果池已满或 runtime 认为需腾空间）
-
runtime.GC()是手动触发完整 GC，会加速清理，但生产环境禁止调用，它会打乱自适应节奏、拉长 STW
为什么 Get() 常拿到脏数据？
因为 GC 从不重置字段，sync.Pool 也不提供任何初始化钩子。每次 Get() 返回的对象，其字段值是上一次使用后的残留状态：
-
*bytes.Buffer的buf.Bytes()可能还带着旧内容，必须调buf.Reset() - 自定义结构体里的
data []byte字段，要用s = s[:0]截断长度，不能s = nil（否则丢掉底层数组） - 含
cache map[string]int的结构体，得遍历delete(m, k)或重用底层数组 - 有
ch chan int字段？必须close(ch)后设为nil，否则下次Get()到的 channel 仍可读写
命中率低不是 Pool 失效，而是你在跨 P 调度
sync.Pool 按 P（逻辑处理器）维护本地缓存，对象 Put() 后大概率留在当前 goroutine 所在的 P 里：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- goroutine 阻塞后被唤醒到别的 P（比如等网络 I/O、调
time.Sleep），就拿不到之前 Put 的对象 - HTTP handler 场景天然高命中——请求处理 goroutine 几乎不跨 P
- 长任务或频繁
runtime.Gosched()的场景，命中率可能跌到 20% 以下 - 别盯着
New调用次数看效果，压测时盯GODEBUG=gctrace=1输出的 MB/s 和benchstat的 B/op 是否下降
什么情况下 sync.Pool 反而更慢？
不是所有对象都适合放 Pool。误用会增加 GC 压力、内存碎片甚至竞态：
- 构造成本本身很低的对象（比如只有几个
int字段的 struct），Pool 的管理开销反而更高 - 生命周期长的对象（被塞进
map、channel或全局变量长期持有），等于人为延长堆驻留时间 - 含未清零指针字段的结构体，会造成隐式引用，让 GC 无法回收底层数组或 map 内存，RSS 暴涨
- 需要严格生命周期控制的资源（如数据库连接、文件句柄），
sync.Pool不 close、不 unlock、不释放，完全不合适
真正容易被忽略的是：你以为自己在复用对象，其实只是在和 GC 赌运气。它可能刚放进去就被收走，也可能滞留两个 GC 周期——别把它当缓存用，也别指望它保活；它的唯一价值，是把“分配→用→丢”里最贵的那步（堆分配）省掉几次。
