Go sync.Pool取回旧对象状态时的重置排查

sync.Pool 取回“旧对象”通常不是 Go 把数据缓存错了，而是调用方把一次使用期的状态留在了可复用对象里。正确做法是把初始化协议放在 Get 之后，把归还协议放在 Put 之前：每次拿到对象都恢复可用初始状态，每次归还前都确认没有外部引用。这样即使池返回的是上一次请求使用过的指针，当前请求也不会读到残留字段。

先确认：旧状态来自复用协议，而不是稳定缓存

官方 sync 文档明确说明，池中的条目可以在任意时刻被自动移除，Get 也可以把池视为空；调用方不能假设某次 Put 的值一定会由下一次 Get 返回。于是排查时要记录三件事：对象是否来自池、Get 后哪些字段被改写、Put 前是否仍有读者。

下面这个结构是排查思路的静态说明图，不是运行截图。真正危险的路径是“旧对象 → 直接读取 → 归还”，中间少了初始化动作。新对象从 New 创建时看起来正常，反而容易掩盖这个问题。

把初始化集中到Get之后

以请求级缓冲对象为例，bytes.Buffer.Reset 只能清空可读数据，业务自定义的状态字段仍要显式恢复。切片字段通常使用 slice[:0] 保留容量；如果旧内容可能通过其他引用泄露，才需要进一步清空元素或重新分配。初始化函数应当是唯一入口，让所有调用方获得同一份契约。

package main

import (
    "bytes"
    "sync"
)

type workItem struct {
    buf   bytes.Buffer
    tags  []string
    code  int
    failed bool
}

var itemPool = sync.Pool{
    New: func() any {
        // New只负责提供可用对象，业务状态仍由prepare统一建立。
        return new(workItem)
    },
}

func prepareItem() *workItem {
    item := itemPool.Get().(*workItem)
    // Reset清理缓冲区，切片长度归零但保留可复用容量。
    item.buf.Reset()
    item.tags = item.tags[:0]
    item.code = 0
    item.failed = false
    return item
}

func releaseItem(item *workItem) {
    // 归还前再次确认调用方已结束使用，避免并发读写同一对象。
    itemPool.Put(item)
}

这里的顺序很重要：先完成 prepareItem，再把指针交给业务逻辑；不要让不同调用点各自决定是否清理。若初始化本身需要读取请求参数，可以把参数传给准备函数，但仍应保持“拿出即初始化”的边界。

Put前检查对象所有权和残留资源

sync.Pool 只适合临时对象。下表可以作为代码审查清单：

另一个边界是类型安全：一个池通常只放一种明确的对象类型。不要为了“通用”把多种结构都塞进 any，否则类型断言失败和状态协议缺失会同时出现。

用可重复边界定位看似随机的问题

排查时先暂时给对象增加一个递增的调试编号，并记录 Get、准备完成、业务结束、Put 四个时间点；不要把日志本身当成并发证明。随后用 go test -race 检查是否存在归还后继续访问。若关闭池后问题消失，说明复用路径暴露了初始化或所有权漏洞，但不等于可以永久关闭池来修复。

如果对象每次都必须深度清理，清理成本已经接近重新分配；如果对象带有稳定的业务身份、连接、锁或长生命周期资源，也不应放进 sync.Pool。这时直接分配、显式复用容器，或为固定生命周期设计专用空闲链表更容易维护。

常见问题

Get一定会返回上一次Put的同一个对象吗？

不会。Get 可以返回任意条目、返回新建对象，甚至把池视为空；代码必须对每次取回都执行初始化。

只调用bytes.Buffer.Reset够不够？

不够。自定义字段、切片、map、错误标志和嵌套对象仍可能保留上次使用的状态，要按对象契约逐项恢复。

为什么Put放在defer里仍可能出错？

如果函数返回后还有协程、回调或切片引用继续访问对象，defer Put 只是让错误更稳定地发生。先结束所有使用者，再归还对象。

一句话收束：sync.Pool 优化的是临时对象的分配压力，不负责替你定义对象状态。把“Get后重置、用完再Put、归还前断开外部引用”写成固定协议，旧状态问题才会从偶发故障变成可检查的工程规则。