sync Pool 取出的对象为什么必须重新初始化

如果把 sync.Pool 当成“永远保存干净对象的工厂”，很快就会遇到一个隐蔽问题：这次请求拿到的 *bytes.Buffer 可能带着上一次使用留下的内容、容量或业务字段。正确做法是把 Get 当成“借到一个可复用容器”，在交给当前请求前重新初始化；使用结束后，再清理并归还。

关键结论：Pool.New 只负责对象缺失时的初始形状，不能替代每次 Get 后的业务状态初始化。Get 不保证命中某个特定对象，池内对象也可能在任意时刻被丢弃。

本文只讨论对象复用边界和清理时机，不展开内存泄漏诊断。官方参考：https://pkg.go.dev/sync#Pool

为什么 Get 拿到的对象不能直接当新对象

Pool.Get 返回的是一个临时对象，而不是一份承诺了默认业务值的新对象。它可能返回池中任意对象，也可能把池视为空；如果设置了 New，才会在这种情况下构造一个值。即使调用了 New，构造函数也只知道对象的结构，不知道当前请求要写入什么状态。

例如一个缓冲对象上一次写过 user=alice，这次请求若直接追加 user=bob，得到的可能是拼接后的脏内容。问题不在 Pool “取错了对象”，而在调用方把“复用容器”误当成“已经初始化的业务对象”。

package main

import (
	"bytes"
	"sync"
)

var bufPool = sync.Pool{
	New: func() any {
		// New 只建立可用的对象形状，不写入某一次请求的业务数据。
		return new(bytes.Buffer)
	},
}

func borrowBuffer() *bytes.Buffer {
	// Get 只表示借到一个缓冲区，不能说明它已经是空的。
	return bufPool.Get().(*bytes.Buffer)
}

因此，初始化责任要放在调用方能看见的位置：拿到对象后先清掉上次的内容，再写入本次请求需要的数据。

Pool.New 负责形状，Get 后负责当前状态

可以把初始化拆成两层。第一层是 New 中的结构初始化，例如返回指针、设置固定容量或准备不可变配置。第二层是每次借用时的状态初始化，例如 Reset 缓冲区、覆盖请求 ID、清空临时切片，或者把可选字段恢复成当前任务要求的值。

type requestBuffer struct {
	buf      bytes.Buffer
	requestID string
}

var requestPool = sync.Pool{
	New: func() any {
		// 固定容量属于对象形状，适合放在 New 中。
		return &requestBuffer{buf: *bytes.NewBuffer(make([]byte, 0, 256))}
	},
}

func acquireRequest(id string) *requestBuffer {
	item := requestPool.Get().(*requestBuffer)
	// 每次 Get 后重置可变状态，避免沿用上一个请求的内容。
	item.buf.Reset()
	item.requestID = id
	return item
}

这里的 requestID 不能依赖 New 设置，因为池中的对象可能不是刚创建的。即使当前实现经常拿到同一个对象，也不能把这种偶然复用顺序写进业务逻辑。

正确的生命周期：Get 后初始化，Put 前清理

调用方持有对象期间，它应当拥有对可变字段的独占使用权。处理完成后，先把不应被下一个调用方看到的内容清理掉，再调用 Put。归还之后不要继续读取或写入同一个指针，否则“清理”和“业务使用”就会互相覆盖。

func handleRequest(id string, payload []byte) {
	item := acquireRequest(id)
	defer func() {
		// 归还前清理请求数据；Put 之后不再使用 item。
		item.buf.Reset()
		item.requestID = ""
		requestPool.Put(item)
	}()

	// 当前调用方只在借用窗口内写入自己的数据。
	item.buf.Write(payload)
	consume(item.requestID, item.buf.Bytes())
}

func consume(id string, data []byte) {
	// 示例业务只消费当前窗口中的数据，不保存池内对象指针。
	_ = id
	_ = data
}

Reset 清空的是缓冲区长度，不一定缩小底层容量；这通常正是临时缓冲复用想要的效果。如果对象还包含引用外部资源的字段，就要在归还前显式断开这些引用，并确保下一个调用方不会观察到上一次任务的状态。

几个容易误判的边界

Get 一定能拿回刚 Put 的对象吗？

不能。官方文档允许 Get 忽略池并把它当成空池，池中的项目也可以被自动移除。代码应能同时处理“拿到旧对象”和“通过 New 得到新对象”两种情况。

只在 Put 前 Reset 就够了吗？

对简单缓冲区来说通常还不够稳妥。把清理放在 Put 前可以降低脏状态进入池的概率，但 Get 后仍应完成本次业务状态初始化，因为对象可能来自旧代码路径，也可能拥有多个可变字段。最可靠的是两端都明确：Get 后建立当前状态，Put 前清理不应跨请求保留的状态。

哪些对象不适合放进 Pool？

需要稳定生命周期、必须关闭或必须精确控制数量的资源，不应仅因为“想复用”就放进 sync.Pool。Pool 更适合短生命周期、可以被丢弃、重新创建成本较高的临时对象。

小结

sync.Pool 优化的是临时对象分配，不是业务状态管理。把 New 看作对象形状初始化，把 Get 后的代码看作当前请求初始化，把 Put 前的代码看作归还前清理，并在归还后停止使用指针，就能把复用收益和状态隔离同时保住。