Go sync.Pool 缓存临时对象的回收边界

我第一次把 sync.Pool 用在日志编码路径时，把它想成了一个“并发安全、自动回收的缓存”。后来才发现，真正重要的边界不在并发安全，而在“对象随时可能消失”：Pool 里的任何对象都可能在没有通知的情况下被移除，Get 也可以忽略池中的内容并把它当成空池。

因此，sync.Pool 只适合复用可丢弃的临时对象。程序必须在每次 Get 为空时照常创建对象；对象从 Get 到 Put 之间由当前调用独占，归还后不能继续使用。它不是带命中保证的业务缓存，也不是连接池。

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

先确认 sync.Pool 只保存可丢弃的临时对象

Go 官方文档把 Pool 定义为一组可单独保存和取回的临时对象，目标是复用已分配但暂时不用的对象，从而减轻垃圾回收压力。文档同时强调：池内对象可能随时被自动移除；Get 返回任意对象，也可能忽略池并视为空。

这意味着正确性不能建立在命中率上。把临时编码缓冲区放进去通常合理，因为没有命中时再创建一个只影响性能；把登录会话、未提交事务、限量许可证或必须关闭的连接放进去则不合理，因为对象消失会改变业务语义或资源生命周期。

把对象生命周期限定在一次借用区间

我现在把一次使用看成一个清晰的借用区间：sync.Pool 提供 Get 与 Put，New 只在空池需要新值时参与；调用方拿到 临时对象 后独占修改，通过 Reset 清理状态，再决定是否归还。图里的连线只是静态关系，不是命中顺序保证。

最容易被忽略的是别名。如果把 bytes.Buffer.Bytes() 返回的切片交给外部，再把 buffer 放回 Pool，下一位使用者可能改写同一底层数组。需要在归还前复制结果，或者让结果在归还前完成消费。

用 New 保证池为空时仍能工作

Pool.New 是可选函数。当 Get 原本要返回 nil 且 New 不为空时，Get 会调用它。官方示例建议 New 通常返回指针类型，因为指针放进接口值时可避免额外分配。New 不能在与 Get 并发时修改。

package encoder

import (
	"bytes"
	"sync"
)

var buffers = sync.Pool{
	New: func() any {
		// 空池时创建全新的临时缓冲区，业务逻辑不依赖缓存命中。
		return new(bytes.Buffer)
	},
}

func encodeLine(s string) []byte {
	buf := buffers.Get().(*bytes.Buffer)
	// Get 返回的对象可能带有旧状态，使用前先清空可见内容。
	buf.Reset()
	buf.WriteString(s)
	buf.WriteByte('\n')

	// 复制结果，避免 Put 后外部切片与复用缓冲区共享底层数组。
	out := bytes.Clone(buf.Bytes())
	buf.Reset()
	buffers.Put(buf)
	return out
}

官方内存模型还规定：如果后续 Get 恰好返回了同一个值，那么此前的 Put(x) 与该 Get 之间存在 synchronizes-before 关系。不过这不是“下一次一定取回 x”的承诺，也不应拿来传递需要可靠交付的业务消息。

在归还点清理状态并限制容量

Reset 通常只把长度清零，不一定释放底层容量。一次异常大的请求可能让 buffer 扩到数 MB；如果仍把它归还，后续小请求可能长期携带这块大容量。我的处理方式是在 release 函数里设置容量上限，超过阈值就不 Put，让普通垃圾回收处理它。

const maxReusableBuffer = 64  maxReusableBuffer {
		return // 峰值大对象直接丢弃，避免占据后续复用槽位。
	}
	buf.Reset() // 清理可见内容后再归还，避免跨请求串数据。
	buffers.Put(buf)
}

容量阈值不是 Go 官方固定值，应根据实际对象尺寸分布决定。包含密钥、令牌或个人数据的结构，仅调用 Reset 可能还不足以擦除底层内存；这类对象要么逐字段覆盖，要么不进入通用 Pool。这里的目标是把“清理策略”固定在归还点，而不是要求每个调用者凭记忆处理。

避开不适合放进 Pool 的对象

官方文档明确指出，Pool 适合被并发、相互独立的客户端静默共享的临时对象；如果 free list 只是某个短生命周期对象的一部分，开销通常难以摊薄，自行维护局部列表可能更高效。Pool 在第一次使用后也不能复制，因此一般放在包级变量或稳定的长生命周期结构里。

静态看，业务调用 从 sync.Pool 借用 *bytes.Buffer，由 Reset 清理并通过 Put 归还；GC 回收 可以移除池内对象。持久资源 则位于另一个边界，不应依赖这套回收语义。

另一个常见错误是 Put 后继续写对象，或者让两个 goroutine 同时持有同一个可变对象。Pool 本身并发安全，不等于被存进去的对象自动并发安全。所有权必须由调用代码保证：谁 Get，谁在独占使用结束后 Put；一旦 Put，就不再碰它。

用基准与内存指标决定是否保留

sync.Pool 是性能工具，不是默认架构。加入前后至少比较 allocs/op、B/op 和延迟分布；对 buffer 类对象还要观察容量分布与堆驻留是否上升。若对象很小、逃逸本来就少，或调用频率不足以摊薄管理成本，Pool 可能只增加类型断言和所有权复杂度。

对我来说，一条可复用的判断路线是：先确认对象可丢弃，再界定借用区间，然后补齐 New、Reset 与容量上限，最后用基准决定是否保留。只要其中任何一步要求“这个对象必须还在”或“Put 后我还要继续用”，就已经越过 sync.Pool 的回收边界。

快速检查表

• 没有命中时，程序是否仍然正确？
• 对象是否能完全重置，且 Put 后没有外部别名？
• 是否会把异常大对象继续放回池中？
• Pool 是否在第一次使用后被复制？
• 池里是否混入连接、句柄、事务或其他持久资源？
• 基准是否证明确实减少了分配或延迟？

常见问题

主动调用 GC 后，Pool 里的对象一定会全部消失吗？

不要依赖具体清理轮次或命中数量。公开契约只保证对象可能随时被移除，正确代码应把每次 Get 都当成可能需要 New。

可以用 sync.Pool 做固定大小的连接池吗？

不合适。连接池通常需要容量、健康检查、超时与关闭语义，而 sync.Pool 不保证对象保存或取回关系。

Reset 后就一定不会泄露旧数据吗？

不一定。Reset 往往只调整长度，底层容量仍在。敏感数据需要覆盖或避免进入通用池，返回给外部的切片也应在 Put 前复制。