Go sync.Pool Get 取不到刚 Put 的对象正常吗

正常。sync.Pool 是“可以丢弃的临时对象复用池”，不是先进先出队列，也不是按 key 保存对象的缓存。Put 之后调用 Get，拿到刚才那个对象、另一个对象、nil，或者在设置了 New 时拿到新建对象，都不能靠业务逻辑预设。

只要程序依赖的是“有一个可用的临时对象”，而不是“必须取回刚 Put 的那个对象”，这个结果就是 sync.Pool 的正常语义。需要可靠保存、按键查找或严格排队的数据，不应交给 Pool。

为什么 Put 之后 Get 仍可能拿不到原对象

官方文档对 Pool 的定位很明确：它缓存已经分配但暂时不用的对象，用来降低重复分配和垃圾回收压力。池中的任意元素都可能在没有通知的情况下被移除；如果池是唯一引用，元素甚至可能随之被回收。因此，下面的代码不能把 got 当作 item 的确定回读：

var pool sync.Pool

item := &bytes.Buffer{}
pool.Put(item)
got := pool.Get()

// got 可能是 item，也可能是 nil；不能依赖它的身份。
_ = got

即使没有显式调用垃圾回收，Get 也被允许把池视为空。并发场景下，其他 goroutine 还可能先取走对象。这里的关键不是“Put 失败”，而是 Pool 从来没有承诺“下一个 Get 必须拿回这一次 Put”。

Get、Put 和 New 应该怎样组成借还边界

如果对象只是字节缓冲区、编码器或短生命周期的临时容器，可以把“没有对象时如何创建”写进 New。借出后先恢复干净状态，业务使用结束后再清理并归还：

var bufferPool = sync.Pool{
    New: func() any {
        // New 只负责池为空时创建一个可用缓冲区。
        return new(bytes.Buffer)
    },
}

func writeRecord(w io.Writer, key, value string) error {
    b := bufferPool.Get().(*bytes.Buffer)
    // 不假设上一个使用者留下了什么内容。
    b.Reset()
    defer func() {
        // 归还前清理状态，避免下一次读到旧数据。
        b.Reset()
        bufferPool.Put(b)
    }()

    b.WriteString(key)
    b.WriteByte('=')
    b.WriteString(value)
    _, err := w.Write(b.Bytes())
    return err
}

New 返回指针类型，通常也更适合放进接口值。这个例子依赖的是“每次得到一个可写的 *bytes.Buffer”，不依赖它是否就是上一次归还的那一个。若把对象归还后仍继续读写，就会和下一位使用者形成数据竞争；归还动作应当视为所有权交接。

这四种现象分别说明什么

如果问题是“对象不见了”，先看调用方是否把 Pool 当成缓存；如果问题是“内容串了”，重点查清理和所有权；如果问题是“偶发 nil”，再看是否缺少 New 或把空结果当成异常。不要通过连续 Put 同一个对象来制造确定性，这只会掩盖设计边界。

什么时候不该使用 sync.Pool

有三类需求与 Pool 的语义冲突：

• 需要按 ID、key 或哈希再次找到同一对象：使用带明确生命周期的 map、缓存或数据库。
• 需要严格先进先出、不能丢元素：使用 channel、显式队列或专门的资源池。
• 对象很小、使用次数少，或者对象只属于一个短命实例：自己管理空闲列表可能更直接。

Pool 适合在多个独立调用者之间静默共享临时对象，并把分配成本摊平。它不是性能开关：要用基准测试比较分配、GC 压力和锁竞争，确认复用收益覆盖了清理与类型断言成本。

相关问题

sync.Pool 是线程安全的吗？

是的，Pool 可以被多个 goroutine 同时使用。但线程安全不等于返回顺序固定，也不等于归还后的对象可以继续被原调用方访问。

设置 New 后还需要判断 Get 是否为 nil 吗？

如果 New 非 nil 且始终返回非 nil 的正确类型，常规借出路径可以直接做类型断言；仍应保证 New 本身不会返回 nil，并在测试中覆盖初始化失败的替代方案。

能不能用 sync.Pool 保存必须保留的结果？

不能。Pool 中的元素允许被自动移除，必须保留的结果应放到有明确所有权和生命周期的数据结构中。