Go sync.Pool Put 传入 nil 的丢弃语义与初始化边界

把nil传入的Put方法时，Go标准库底层会直接走丢弃逻辑，不会把这个nil对象存入池的内部存储空间，完全不会影响后续Get操作的返回结果；只有你通过New字段定义的初始化函数，才会在池内无可用对象时被调用生成全新实例。

Put(nil) 与 typed nil 的边界

Go 官方实现先判断 x == nil，成立时立即返回；因此未类型化 nil 不会占据本地槽位，也不会进入共享队列。这个判断针对的是接口值本身，而不是接口内部动态值的所有可能形态。

下面的例子把两种情况放在一起。第一处调用没有任何池内对象；第二处虽然放入的是 nil 指针，但接口里仍保存着指针类型信息，Put 的参数并非 nil 接口。

package main

import (
	"fmt"
	"sync"
)

type Item struct{ Name string }

func main() {
	var pool sync.Pool

	pool.Put(nil) // 未类型化 nil：Put 直接返回，不会进入池
	fmt.Printf("%#v\n", pool.Get()) // 输出 nil，说明池仍为空

	var item *Item
	pool.Put(item) // typed nil：接口带有 *Item 类型，不能按 nil 接口处理
	value := pool.Get()
	fmt.Printf("%T, %v\n", value, value == nil) // *main.Item, false

	if got, ok := value.(*Item); ok && got != nil {
		fmt.Println(got.Name) // 只有指针非 nil 才能安全访问字段
	} else {
		fmt.Println("需要重新创建 Item") // 类型正确但指针为空时走兜底
	}
}

工程上不要只写 if value == nil 就开始解引用。对池中对象，至少同时检查类型断言和指针值；如果池的来源复杂，还要拒绝不符合当前调用方约定的动态类型。

Get 与 New 的初始化路径

Get 会先尝试当前 P 的私有槽，再尝试共享数据和其他 P 的对象；这些位置都没有可返回值时，才检查 New。因此 New 是“空结果生成器”，不是把 nil 转换成对象的 Put 钩子。

var bufferPool = sync.Pool{
	New: func() any {
		return new([]byte) // 池为空时创建一个明确类型的临时缓冲
	},
}

func acquire() *[]byte {
	value := bufferPool.Get() // Get 最终为空时才调用 New
	buf, ok := value.(*[]byte)
	if !ok || buf == nil {
		return new([]byte) // 防御 typed nil 或错误类型，避免后续解引用崩溃
	}
	*buf = (*buf)[:0] // 复用前清掉上一位调用者留下的长度
	return buf
}

func release(buf *[]byte) {
	if buf == nil {
		return // nil 不应被当成可复用对象放回池中
	}
	*buf = (*buf)[:0] // 归还前重置可见状态
	bufferPool.Put(buf)
}

这个模式把“创建”和“复用”分开：New 负责给出合法类型，调用方负责确认类型、清理可见状态，归还函数负责拒绝 nil。即便代码逻辑正确，池里的对象也可能被运行时在任意时机丢弃，所以结果不能依赖某个对象一定还在。

把 nil 边界落到复用代码

如果对象需要按 key 精确命中、跨请求稳定保留、可统计命中率，应该使用显式缓存或数据结构；如果对象不能丢失，也不要用 sync.Pool 代替队列。它最适合的是生命周期短、可以随时重新创建、复用能减少分配压力的临时对象。

相关问题

为什么 Put(nil) 后 Get 仍然是 nil？

因为 Put 对未类型化 nil 直接返回，池中没有新增对象；没有可取对象且 New 未设置时，Get 就会返回 nil。

typed nil 会触发 Pool.New 吗？

通常不会。只要池返回了那个 typed nil 接口，Get 的结果就不是 nil 接口，New 不会介入；调用方必须自行检查断言后的指针。

给 Pool 设置 New 后还要检查类型吗？

要检查。New 返回的是 any，它只约定“空池时生成一个值”，不会替调用方保证所有历史归还值都具有正确动态类型。