Go sync.Pool 里的对象为什么会消失

Go 的 sync.Pool 里的对象“消失”通常不是内存泄漏，也不是 Put 失效，而是用错了它的承诺范围。官方文档明确说明：池中任何元素都可能在没有通知的情况下被自动移除；如果池里只有这一份引用，对象还可能被回收。因此，sync.Pool 只能用来降低临时对象的分配压力，不能当作必须命中的业务缓存。

把它当作“有就复用、没有就重新创建”的临时对象来源，而不是“放进去以后一定还在”的仓库。只要代码允许 Get 返回新对象，所谓消失就是正常行为。

先确认 sync.Pool 的承诺范围

sync.Pool 是并发安全的临时对象池。调用 Put(x) 后，x 只是进入“可能被复用”的集合；运行时可以在任意时刻清理它，调用方不会收到回调。即使没有发生明显的 GC，下一次 Get 也不应依赖某个具体对象仍然存在。

这也是它和 map 缓存的根本区别：缓存通常围绕 key、命中和淘汰策略组织，而 Pool 只关心一批暂时闲置的对象。像格式化缓冲区、短生命周期的字节缓冲等适合用 Pool；用户会话、配置、订单状态这类持久业务状态就不应该放进去。

图1：分层查看 Pool、临时对象与业务缓存的边界，理解对象为什么可以被无通知地移除。

用 New、Get、Put 组成可回收的复用路径

最稳妥的写法是让 New 负责兜底创建，让每次使用者在拿到对象后先恢复干净状态，使用结束再归还。下面以 bytes.Buffer 为例：

package main

import (
    "bytes"
    "fmt"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        // 没有可复用对象时，创建一个新的指针对象。
        return new(bytes.Buffer)
    },
}

func formatMessage(name string) string {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 上一个使用者可能留下内容，取出后先恢复初始状态。
    buf.Reset()
    defer bufferPool.Put(buf)

    buf.WriteString("hello, ")
    buf.WriteString(name)
    // 返回字符串后，调用方不再依赖池中 buffer 的后续状态。
    return buf.String()
}

func main() {
    fmt.Println(formatMessage("gopher"))
}

这里的关键不是“永远复用同一个 buffer”，而是每次拿到的值都满足可使用条件。New 返回 *bytes.Buffer，可以避免把较大的值直接装进接口；Reset 消除了前一次内容；defer 保证正常返回路径会归还对象。若中途发生 panic，归还动作也会执行，但业务代码仍要确保不会把仍在使用的对象交给其他 goroutine。

理解 GC 与对象消失的关系

垃圾回收只关心仍然可达的对象，而 sync.Pool 对内部元素采用的是“可丢弃”语义。池保存的引用本身不构成业务上的永久所有权，所以运行时清理 Pool 后，下一次 Get 可能走 New，这正是设计允许的结果。

不要根据一次压测或一次 GC 日志总结出“每次 GC 都会清空 Pool”的固定规律。应用只能依赖文档承诺的最小行为：对象可能被删除，Get 必须随时能够得到新对象。若对象里带有必须保留的状态，清理后状态丢失就会变成业务 bug，此时应移出 Pool。

如果你观察到 New 调用次数变多，先把它当作复用机会减少，而不是把它当作数据丢失。真正需要定位的是：对象是否被正确 Put、使用时是否发生了过度扩容、对象池是否被错误地频繁创建，以及当前负载是否让池里的对象很快变得不可复用。

图2：图中按对象角色区分 New、Get、Put、使用者和自动移除；这些是静态关系，不代表对象一定按固定顺序返回。

划清临时对象和业务缓存的边界

可以用三个问题做判断：数据丢了能不能重新创建？是否需要按业务 key 精确取回？是否要求跨 GC、跨请求或跨时间一直存在？只要后两个问题有一个答案是“需要”，就不应使用 sync.Pool 作为唯一存储。

例如图片处理中的临时字节片段可以在缺失时重新分配；而登录会话、限流计数、配置快照和订单状态必须选择 map、带过期时间的缓存、数据库或其他有明确生命周期的组件。若只是一个短生命周期对象的空闲列表，且你需要精确控制容量和释放时机，自己维护受锁保护的 free list 反而更容易表达约束。

按清单排查复用率异常

• 确认 sync.Pool 是长生命周期对象，而不是每个请求、每次循环重新创建。
• 检查 Get 后是否做了类型判断或由 New 统一返回预期类型。
• 检查 Put 前是否 Reset，以及归还后是否仍有 goroutine 持有同一对象。
• 不要把 Get 命中某个具体指针当作测试断言；断言应放在输出内容和业务结果上。
• 如果对象不能丢、必须按 key 命中或需要明确淘汰，请换成有持久语义的缓存或容器。

常见问题

为什么 Put 之后马上 Get 也可能拿不到原对象？

Get 允许选择任意对象，也允许忽略池并把它视为空；因此“刚 Put 的对象一定被取回”不是 API 契约。

给 sync.Pool 设置 New 后还会返回 nil 吗？

只要 New 非 nil 且它本身返回非 nil，池在没有可用元素时会调用它。实际代码仍要保证类型断言与初始化逻辑一致。

sync.Pool 适合保存连接、文件或事务吗？

通常不适合。连接、文件和事务包含需要确定释放、健康检查或上下文绑定的资源，应该使用专门的资源池或显式生命周期管理。

把“可能复用”当成唯一保证

Go sync.Pool 里的对象消失，是临时对象池主动让渡持久性的结果。正确的使用方式是：Get 后初始化，使用完清理并 Put，同时让 New 随时承担重新创建。只要业务数据不能丢，就不要把 Pool 当缓存；只要对象可以重新生成，它的复用率下降就只是性能现象，而不是数据正确性问题。