sync.Pool不会自动清理对象，仅在每次GC前强制清空整个池（置nil），不调用析构逻辑；它只是无状态复用桶，非资源池，不保证对象存活或复用路径。
sync.Pool 不会自动清理对象，也不会在 GC 时“回收”池中对象——它只在 GC 前清空整个池（即丢弃所有缓存对象），且不调用任何析构逻辑。
这是最常被误解的一点：很多人以为 sync.Pool 是带生命周期管理的“智能缓存”，其实它只是个无状态、无回调、纯内存复用的桶。
sync.Pool 的清空时机很明确：每次 GC 开始前
- Go 运行时会在 标记阶段启动前（即
Mark阶段开始瞬间）遍历所有全局sync.Pool实例，把它们的poolLocal.private和poolLocal.shared全部置为nil。 - 这个动作是强制的、不可取消的、不通知用户的。
- 清空后，下一次
Get()若池为空，就调用New函数新建对象。
这意味着：
- 池中对象不会“活过一次 GC”；
- 你不能依赖池中对象保持某种状态（比如打开的文件句柄、未 flush 的 buffer）；
- 如果
New创建的是带资源的对象（如*bytes.Buffer），必须确保它可安全重用（例如调用Reset()）；否则残留数据会污染后续使用。
为什么没有 Close 或 Finalize 回调？
因为 sync.Pool 的设计目标只有一个：降低小对象高频分配带来的 GC 压力。它不是资源池（resource pool），也不是连接池（connection pool）。
立即学习“go语言免费学习笔记（深入）”；
- 它不跟踪对象归属，不区分 goroutine，不保证对象复用路径；
- 它不介入对象语义，也不感知对象是否“干净”；
- 它甚至不保证
Put(x)后x真的被缓存——如果池已满或本地 P 缓存饱和，Put可能直接丢弃。
所以常见错误包括：
-
Put(io.Reader)但没重置底层 buffer → 下次Get()读到脏数据； -
Put(struct{ fd int })但没关闭fd→ 文件描述符泄漏（sync.Pool不关 fd）； - 期望池在程序退出前自动释放资源 → 实际上，main 退出时池还没来得及清空，对象随进程一起消失，资源靠 OS 回收。
如何安全地复用对象？
关键不在“清理”，而在“重置”。典型模式是：
- 在
New中返回已初始化的对象； - 在
Put前手动重置（如b.Reset(),slice = slice[:0],mapclear(m)）； - 把重置逻辑封装进自定义方法，避免漏写。
例如：
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// 使用时：
b := bufPool.Get().(*bytes.Buffer)
b.Reset() // 必须！否则可能残留上次写入内容
b.WriteString("hello")
// ...
bufPool.Put(b) // 此时 b 是干净的
注意：b.Reset() 不等于 b = new(bytes.Buffer) ——后者触发新分配，违背了用 Pool 的初衷。
最容易被忽略的点
-
sync.Pool的本地性（per-P）意味着：一个 goroutinePut的对象，大概率只能被同个 P 上的 goroutineGet到；跨 P 获取需走共享队列，有锁开销，且更易被 GC 清掉。 - 如果你的负载是短时 burst + 长时间 idle，池可能在 idle 期就被 GC 清空，burst 来临时又得频繁
New——这不是 bug，是设计使然。 -
sync.Pool对大对象（>32KB）效果差，因为大对象绕过 mcache 直接走 mheap，复用率低，还可能加剧内存碎片。
真正要“清理资源”，该用 runtime.SetFinalizer（慎用，有性能代价）或显式 close/flush 模式，而不是指望 sync.Pool。
