sync.Pool 的对象由 GC 唯一清空，不能手动释放；New 函数必须返回干净对象，Get 后需显式 Reset；Put 必须与 Get 同 goroutine，否则 panic；命中率低时需排查 GC 频率、对象复用逻辑或改用其他方案。
Go 的 sync.Pool 不会主动触发 GC，但 GC 会清空它
很多人以为调用 runtime.GC() 后 sync.Pool 里的对象就“安全回收”了，其实正好相反：GC 是唯一能清空 sync.Pool 的机制，而且它只在**某次 GC 开始前**扫描并丢弃所有未被引用的池中对象。这意味着：
-
sync.Pool中的对象生命周期完全由 GC 控制，你无法手动“释放”或“清空”某个 Pool 实例 - 如果对象持有大内存（比如
[]byte切片）或外部资源（如文件描述符），仅靠 Pool 不足以防止泄漏——必须在New函数里显式复位或重置 - 频繁触发 GC（例如通过
debug.SetGCPercent(1)）会让 Pool 命中率暴跌，因为刚放进去的对象很快被扫掉
自定义 sync.Pool 时，New 函数必须返回可复用、无残留状态的对象
这是最容易出错的地方。Pool 不会校验你返回的对象是否干净，它只管拿、放、缓存。如果你在 New 里返回一个带指针字段的 struct，而没清空这些字段，下次 Get() 拿到的就是脏数据。
- 错误写法：
New: func() interface{} { return &MyStruct{data: make([]int, 1024)} }—— 每次 Get 都可能拿到上次遗留的data内容 - 正确写法：
New: func() interface{} { return &MyStruct{} }，并在MyStruct.Reset()方法里清空字段，Get 后立刻调用obj.Reset() - 更稳妥的做法是把 Reset 做进 Pool 封装层，避免使用者漏调；例如封装成
GetObj()方法，内部自动 Reset
Pool 对象不能跨 goroutine 归还，否则触发 panic
sync.Pool 的实现依赖 P（processor）本地缓存，Put 操作必须和 Get 在同一个 P 上执行。在以下场景容易踩坑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- HTTP handler 中 Get 对象，然后启动 goroutine 异步处理，并在 goroutine 里 Put —— 这是非法的，运行时会 panic “putting wrong type into pool” 或直接 crash（取决于 Go 版本）
- 使用
time.AfterFunc、http.TimeoutHandler等隐式切换 goroutine 的机制后归还对象 - 解决方案只有两个：要么确保 Put 和 Get 在同一 goroutine；要么改用带锁的全局对象池（牺牲性能换安全），但通常不推荐
GC 期间 Pool 清空不可预测，高吞吐服务需监控 PollHitRate
Go 1.21+ 可通过 debug.ReadGCStats 或 pprof 获取 sync.Pool 命中率，但生产环境更实用的是打点观测：
立即学习“go语言免费学习笔记（深入）”；
- 用
expvar.NewInt("pool_hits")和expvar.NewInt("pool_misses")手动计数，在 Get/Pop 路径埋点 - 命中率持续低于 70% 说明对象复用效果差，可能原因包括：New 创建成本低（不如直接 new）、对象大小波动大（导致 Pool 分桶失效）、GC 频繁
- 注意：Go 的 Pool 是 per-P 缓存，不是全局 LRU，所以对象不会“老化淘汰”，只会等 GC 扫描时统一丢弃——这点和 Java 的
ObjectPool完全不同
真正难处理的是那些需要跨 goroutine 生命周期管理的对象，比如连接、上下文绑定的 buffer。这种时候 Pool 往往只是半解，得配合 context.CancelFunc 或 finalizer 做兜底，但 finalizer 本身又不可靠。实际项目里，宁可多分配几次内存，也别让 Pool 成为 bug 温床。
