sync.Pool对象在第N次GC前Put后，存于local池；第N+1次GC时移入victim缓存；第N+2次GC才真正释放，但具体清理时机不可预测，且Get永不访问victim。
sync.Pool 中的对象不是“用完就丢”，也不是“永远不丢”——它被 GC 控制，但又不完全听 GC 的；你无法预测某次 Put 进去的对象具体在哪次 GC 后消失，只能知道它最多活到“下下一次 GC”前。
sync.Pool 对象到底什么时候被清理？
每次 Go runtime 触发 GC 前（STW 阶段），会调用 poolCleanup 函数，执行两件事：
- 把当前所有
P的local池整体“降级”为victim缓存（只读、不接受Put） - 把上一轮的
victim直接丢弃，交由 GC 回收
所以对象生命周期是：第 N 次 GC 前 Put → 存在 local 中 → 第 N+1 次 GC 后进入 victim → 第 N+2 次 GC 时才真正释放。但注意：Get 永远不查 victim，只从 local 取；victim 是纯过渡机制，只为缓解 GC 突刺带来的复用率断崖下跌。
为什么手动调用 runtime.GC() 清不掉 Pool？
runtime.GC() 触发的是完整 GC 流程，但它不会提前触发 poolCleanup。该函数只在 runtime 自动调度的 GC 前执行，和你手动调用无关。
立即学习“go语言免费学习笔记（深入）”；
- 你在代码里写
runtime.GC()，log 里能看到gc N @X.Xs，但sync.Pool.local不会因此变空 - 池中对象是否被清，取决于它是否已进
victim，以及底层内存是否被 GC 标为不可达 - 别指望靠
runtime.GC()“强制清空池”——它既不保证命中，也不控制victim生命周期
对象没 Reset 就 Put，会导致什么？
这是最常踩的坑：victim 中的对象字段值完全随机，New 函数绝不会在 victim 命中时触发，所以你拿到的可能是残留旧数据的脏对象。
- 例如
buf := pool.Get().(*bytes.Buffer)，如果没调buf.Reset()就Put，下次从victim拿出来的buf里可能还带着上次的字符串 - 更危险的是：如果
buf底层数组因逃逸留在堆上，而你没重置指针，它会阻止那块内存归还 OS - 正确做法是：每次
Get后、使用前必须显式重置关键字段，比如slice = slice[:0]或buf.Reset()
高频短连接场景下，Pool 为什么像“没用”？
当请求周期极短（比如 HTTP handler 内循环 Get/Put 数万次），且 GC 间隔内新分配对象远超池容量时，sync.Pool 实际上退化成“分配器”而非“缓存器”。
- 对象刚
Put进去，还没来得及被其他 goroutine 复用，就被 GC 清走 —— 不是 bug，是设计使然 - 此时内存增长、GC 频繁，根本原因是复用率低，而非 Pool 本身失效
- 真正要优化的不是 Pool 调用频次，而是对象生命周期与 GC 周期的匹配度：比如合并小 buffer、延迟
Put、或改用固定大小预分配切片
最容易被忽略的不是“Pool 什么时候清”，而是“对象底层数组是否还在被隐式引用”。逃逸分析 + 显式 Reset + 不长期持有 dst 切片，这三者缺一不可。
