Go sync.Pool 取到 nil 怎么设计对象兜底

Go 的 sync.Pool.Get 取到 nil 不一定是异常：空池可以返回 nil，运行时也允许忽略池内容；如果设置了 Pool.New，只有在原本会返回 nil 时才会调用工厂。最稳妥的做法是把“如何创建一个可复用对象”放进 New，再在调用点保留类型断言和必要的状态清理。

官方地址：https://pkg.go.dev/sync#Pool

本文只讨论临时对象的 nil 兜底，不把 sync.Pool 当成连接池、缓存数据库或可靠队列。两张配图都是静态结构说明图，不是运行截图。

先理解 Pool.Get 为什么可能返回 nil

Pool 是一个可并发使用的临时对象集合。Put 放入的对象可能在之后任意时间被自动移除，调用方不能假设“放进去的对象一定还能取回来”，也不能把一次 Get 当成固定的先进先出读取。

package main

import (
    "fmt"
    "sync"
)

func main() {
    var pool sync.Pool

    // 零值 Pool 可以直接使用，但没有 New 时，空池的 Get 可能得到 nil。
    value := pool.Get()
    if value == nil {
        fmt.Println("pool is empty")
        return
    }

    // Put 只表示允许复用，不表示对象会一直留在池里。
    pool.Put("temporary")
}

因此，下面这种断言并不总是安全：

// 未配置 New 时，空池返回 nil，直接断言会触发 panic。
buffer := pool.Get().(*bytes.Buffer)

这里的根因不是并发读写冲突，而是把“池里当前有对象”误当成了 API 保证。图1把调用者、Pool.Get、临时对象存储和 nil 分支放在同一张静态关系图中，帮助区分对象池的可选复用与业务层的必需对象。

用 New 把对象初始化责任集中起来

Pool.New 的签名是 func() any。当 Get 本来会返回 nil 时，如果 New 非空，Get 会返回工厂的结果。对于同一篇文章、同一个包内的对象池，工厂应稳定返回同一种类型，调用点就能用一次明确的类型断言接住它。

package bufferpool

import (
    "bytes"
    "sync"
)

var buffers = sync.Pool{
    New: func() any {
        // 返回指针便于复用可变缓冲区，也让断言类型唯一。
        return new(bytes.Buffer)
    },
}

func Acquire() *bytes.Buffer {
    // New 已经覆盖空池情况；若工厂被改坏，断言会尽早暴露配置错误。
    return buffers.Get().(*bytes.Buffer)
}

func Release(buffer *bytes.Buffer) {
    // 归还前清除上一次使用留下的字节，避免下一个调用者看到旧内容。
    buffer.Reset()
    buffers.Put(buffer)
}

这里的 New 解决的是“没有对象时如何创建”，Release 解决的是“归还前如何恢复可复用状态”。两者不要混成一个含糊的“缓存命中”概念：对象池不承诺命中，也不替调用方清空业务字段。

官方文档还特别说明，New 不能与 Get 并发修改。实际项目中应在初始化阶段设置工厂，之后只并发调用 Get 和 Put。如果需要按租户、连接地址或权限生成不同对象，就不应该把这些互不兼容的类型混进同一个池。

类型断言与 nil 检查要放在正确位置

如果对象池没有 New，或某个调用路径必须容忍工厂为空，可以采用安全断言。注意接口值里的“类型为指针但指针值为 nil”与接口本身为 nil 是两种情况，兜底代码要看清楚实际类型。

package bufferpool

import "bytes"

func AcquireSafely(pool *sync.Pool) *bytes.Buffer {
    // 先拿出 any，避免把 nil 接口直接做强制断言。
    value := pool.Get()
    if value == nil {
        // 这里可以创建一次性对象，但它不一定会回到池里。
        return new(bytes.Buffer)
    }

    buffer, ok := value.(*bytes.Buffer)
    if !ok || buffer == nil {
        // 错误类型说明池的所有权或初始化约定被破坏，不能继续复用。
        return new(bytes.Buffer)
    }
    return buffer
}

这个函数的重点是把错误类型和 nil 指针从“类型断言 panic”变成“新建一次性对象”。如果错误类型代表严重的程序配置问题，也可以返回错误或记录告警；不要静默把多个业务对象混成一个池。示例中的兜底新对象没有自动放回池，归还责任仍由调用方决定。

如果能控制池的初始化，优先选择上一节的 New，而不是让每个调用点重复写 nil 分支。安全断言更适合边界层、插件加载或迁移期代码。

Put 之前清理状态并明确所有权

对象池只适合“临时、可丢弃、重新初始化”的对象。一个请求借到缓冲区后，应该负责写入自己的内容、在归还前清理状态，并确保没有把缓冲区的切片继续交给异步任务或外部调用者。

package logger

import (
    "bytes"
    "sync"
)

var logBuffers = sync.Pool{
    New: func() any {
        // 工厂只负责创建，不携带上一次请求的业务内容。
        return new(bytes.Buffer)
    },
}

func Format(prefix, message string) []byte {
    buffer := logBuffers.Get().(*bytes.Buffer)
    defer func() {
        // 归还前清空缓冲区；Put 后不能再继续使用同一个 buffer。
        buffer.Reset()
        logBuffers.Put(buffer)
    }()

    buffer.WriteString(prefix)
    buffer.WriteByte(' ')
    buffer.WriteString(message)

    // 返回独立副本，避免调用者持有池中对象的底层数组。
    return append([]byte(nil), buffer.Bytes()...)
}

defer 让正常返回和后续新增的提前返回共享归还路径；而 append([]byte(nil), ...) 把结果与池中缓冲区解绑。若直接返回 buffer.Bytes()，调用方在下一次复用后可能读到已被改写的底层数组，这比单纯的 nil 问题更难排查。

图2展示“工厂创建—调用者使用—独立结果—清理后归还”的静态对象关系。它不表示真实执行顺序，也不意味着 Pool 会保证某个对象一直存活。

判断 sync.Pool 是否适合当前对象

一个简单判断是：对象丢失后，程序能否无损地重新创建？如果答案是否定的，就不要用 sync.Pool 保存它。

sync.Pool 的价值是缓解临时分配压力，而不是保证复用率。将它当作连接池会遗漏连接上限、空闲回收和故障重建；将它当作业务缓存会把“可被丢弃”错误地扩展到必须保留的数据。

用表格收束排障路径

最后记住三个边界：Get 不保证命中，New 只负责空值时创建，Put 也不替你清理状态。把这三件事分别封装在 Acquire、使用函数和 Release 中，nil 兜底就会从零散补丁变成清晰的对象生命周期设计。

配置了 New 后还要判断 nil 吗？

如果初始化代码可信且工厂始终返回正确类型，调用点可以使用明确的类型断言；边界层或可替换配置仍可使用安全断言。不要把“通常不会 nil”写成 API 永远不会 nil 的承诺。

Pool.Get 会按 Put 的顺序返回对象吗？

不会。Get 可以选择任意对象，也可能把池当作空池处理。业务若依赖顺序，应该使用队列或带顺序保证的数据结构。

Put 后还能继续读原对象吗？

不应该。Put 表示对象交回池，之后可能马上被其他调用者复用；先复制需要返回的数据，再清理并归还。