sync.Pool 缓存对象导致状态串线的清理方式

我排查过一种很隐蔽的并发问题：同一个接口偶尔返回了上一个请求的错误信息，或者新请求拿到的缓冲对象里还残留旧字段。看到代码里用了 sync.Pool 后，先不要把它当成“缓存失效”。更常见的根因是对象被复用时，上一轮业务状态没有在交接边界清掉。

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

稳定做法是把 Pool 只用于降低临时分配，把真正的业务状态清理收口到一个 Reset 方法，并在对象离开本次使用范围前调用它。这样即使下一次 Get 拿到的是同一个对象，也不会把旧请求的状态带过去。

先区分对象复用和稳定缓存

sync.Pool 是并发安全的临时对象池，适合复用缓冲区、临时切片包装器或短生命周期的格式化对象。它并不承诺某个对象一定会留在池里：池中的元素可能在任意时刻被运行时自动移除，调用方也必须接受 Get 返回 nil 的情况。

因此，下面这种思路很危险：把用户身份、权限、租户编号或上一次请求的错误状态写进对象，然后只在成功路径清空。请求一旦走到提前返回或错误分支，旧状态就可能被 Put 回池，下一次取出后形成“串线”。

把清理责任放进 Reset

我通常先把对象分成两类字段：可以复用底层容量的字段，以及必须恢复业务零值的字段。字节缓冲区可以保留底层数组容量，但长度要归零；字符串、错误、标志位、关联 ID 和临时 map 则要回到下一次使用所需的初始状态。

package main

import "sync"

type WorkBuffer struct {
	data  []byte
	requestID string
	found bool
	labels map[string]string
}

// Reset 只保留可复用的底层容量，清掉会跨请求传播的业务状态。
func (w *WorkBuffer) Reset() {
	w.data = w.data[:0]
	w.requestID = ""
	w.found = false
	// map 可能带着旧键值，逐项删除比保留旧业务状态更安全。
	for k := range w.labels {
		delete(w.labels, k)
	}
}

var workPool = sync.Pool{
	// New 只负责提供可用对象，不能把它当成持久化初始化入口。
	New: func() any {
		return &WorkBuffer{labels: make(map[string]string)}
	},
}

func handle(requestID string) {
	w := workPool.Get().(*WorkBuffer)
	// 无论成功、失败还是提前返回，都在交还前清理本次状态。
	defer func() {
		w.Reset()
		workPool.Put(w)
	}()

	w.requestID = requestID
	w.data = append(w.data, []byte("payload")...)
	// 这里继续处理当前请求，不能读取上一次请求留下的字段。
}

示例里把 Reset 放在 Put 前，是为了让“交还池之前必须清理”成为固定结构。另一种可行写法是在 Get 后立即 Reset，但只靠调用方记忆容易漏掉新入口；如果团队选择这种写法，也应把获取和清理封装成同一个辅助函数。

哪些字段应该清理，哪些状态不该进 Pool

排查时不要只搜索 Pool.Put，还要沿着对象字段看它是否保存了跨请求所有权。下面的判断可以作为边界：

还要记住两个容易混淆的事实：Pool 的 Get 与 Put 可以被多个 goroutine 并发调用，但从池中取出的对象仍然要由当前使用者独占；另外，Pool 里的对象可能被垃圾回收清掉，所以它不能用来保存必须存在的配置、队列消息或业务结果。

状态串线时按这张清单排查

1. 确认每一个 Put 前是否经过统一的 Reset，尤其检查错误返回、超时和提前退出分支。
2. 逐个标记对象字段：哪些只保存临时容量，哪些含请求身份、错误、开关或结果；后者必须清理或移出 Pool。
3. 确认 Get 的结果可能为 nil，或者统一设置 New，不要把 Pool 当成永远有对象的容器。
4. 确认取出的对象没有被两个 goroutine 同时使用，也没有在 Put 后继续写入。
5. 如果业务需要命中、过期和一致性语义，换成有明确生命周期的缓存或数据结构，不要继续给 sync.Pool 添加“保活”逻辑。

这类问题最有效的切入点不是猜哪一次 GC 删除了对象，而是画出“当前请求获得对象—写入业务字段—清理—交还”的边界。只要清理职责集中且所有退出路径都经过它，复用本身就不会再制造状态串线。

相关问题

Reset 应该放在 Get 后还是 Put 前？

两种位置都可以成立，但必须保证每个使用者都执行到。把 Reset 和 Put 放进同一个 defer 通常更不容易漏掉错误路径；如果对象可能来自其他来源，则在 Get 后再做一次轻量初始化也更稳妥。

sync.Pool 能保存热点配置吗？

不适合。配置是需要稳定存在并且可按版本、读写或失效策略管理的业务数据，而 Pool 只承诺临时复用，元素可能被自动移除。

为什么清空切片还要保留容量？

s[:0] 只把可见长度归零，底层数组仍可在下一次追加时复用；但如果切片持有敏感或超大数据，应该结合生命周期决定是否释放底层引用，不能机械保留。