Go sync.Pool 界定 GC 后对象可用性

Go 的 sync.Pool 不能按“放进去就一直在”的容器理解。GC 或运行时清理后，池中的对象可能已经不存在；下一次 Get 既可能拿到其他对象，也可能直接走 New。所以，GC 后的正确结论不是“对象还能不能取回”，而是“即使取不到，程序能不能重新得到一个状态干净、可以使用的临时对象”。

把 Pool 当作可丢弃的复用机会：用 New 处理空池，用初始化函数恢复默认状态，不把池内对象当作业务数据或稳定缓存。

本文要点：对象可以被 GC 相关清理移除；Get 不保证对应某一次 Put；安全复用依赖调用方自己的状态重置和所有权约束。

GC 后为什么不能依赖池中对象

官方文档给出的契约是：Pool 中任意项目都可能在没有通知的情况下自动移除；如果池是最后一个引用，对象还可能被回收。Get 选择的是任意项目，也可以把池视为空，即使之前调用过 Put。这意味着 Pool 的容量、命中率和某个对象的存活时间都不是业务逻辑可以依赖的结果。

因此，适合放入的是可重新创建的短生命周期对象，例如编码缓冲区、临时字节切片或格式化辅助结构。不适合放入订单状态、登录会话、必须持久保存的配置，或者依赖固定容量的资源句柄。

用 New 把空池变成可处理的分支

如果没有设置 New，空池的 Get 会返回 nil；设置后，Get 在拿不到对象时会调用它。初始化函数只负责构造“刚创建时可用”的对象，不能假设它是从上一轮请求复用而来。

var bufferPool = sync.Pool{
	New: func() any {
		// New 只创建临时对象，不保存请求或用户状态。
		return new(bytes.Buffer)
	},
}

func render(prefix string, body []byte) []byte {
	b := bufferPool.Get().(*bytes.Buffer)
	// 无论对象来自 New 还是复用，都先恢复空状态。
	b.Reset()
	defer bufferPool.Put(b) // 返回前必须确认本次写入已经结束。

	b.WriteString(prefix)
	b.Write(body)
	return append([]byte(nil), b.Bytes()...)
}

示例中返回值复制了一份，是因为 Put 之后缓冲区的底层数组可能再次被改写。若直接把 b.Bytes() 交给调用方，再把 b 放回池，调用方就会持有一个不再归自己控制的切片。

Get、重置、使用、Put 的边界

一个稳定的复用顺序是：取出对象，清理可变字段，完成本次使用，确认没有其他 goroutine 继续引用，最后归还。不要用“刚刚 Put 的对象一定还在”来测试 GC 行为，也不要通过对象地址判断命中；Get 明确允许返回任意项目。

Put 与返回同一对象的 Get 之间有同步关系，但这只说明发生了内存同步，不等于对象必然会被返回，更不等于它会跨 GC 周期永久保留。对象若带有大容量切片、错误值或敏感内容，应在归还前按业务需要清理，必要时直接丢弃而不是继续放回。

四个判断决定是否应该使用 Pool

如果池命中率低，不要先把它改造成“永不清理”的缓存；先确认对象是否真的有高频分配压力，再用基准测试比较分配、GC 和锁竞争的变化。Pool 的价值是降低临时分配压力，而不是提供容量上限、淘汰顺序或数据可靠性。

常见疑问

GC 后调用 Get 一定返回 nil 吗？

不一定。可能返回仍在池中的任意对象，也可能调用 New，未设置 New 时才可能得到 nil。

Pool 能不能保存必须复用的连接？

不应把连接的可用性建立在 Pool 上。连接需要明确的生命周期、健康检查和关闭策略；Pool 只适合丢失后可以安全重建的临时对象。

参考：Go sync 官方文档与标准库源码。本文图片均为围绕对象生命周期和边界关系生成的原创静态说明图，不是截图或运行证据。