Go sync.Pool 怎样避免复用对象残留旧状态

如果从 sync.Pool 取出的对象偶尔带着上一次请求的字段，最稳妥的处理不是假设 Pool 会自动初始化，而是把对象生命周期写清楚：Get 后由当前调用方建立可用状态，业务完成后在 Put 前清理可变字段。因为 Pool 只保证临时对象可以被并发安全地复用，并不保证下一次 Get 一定拿到新对象，也不保证 Put 进去的对象会一直存在。

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

把 sync.Pool 当作“可随时丢弃的临时对象池”，而不是缓存业务数据的仓库。只要对象可能被再次使用，就必须在自己的代码里明确重置规则。

一、先分清 sync.Pool 能保证什么

sync.Pool.Get 会从池中取出一个任意对象，也可能调用 New 创建对象；如果池中没有对象且没有 New，返回值就是 nil。取出的对象可能是之前通过 Put 放回的同一个实例，调用方不能依赖它的字段仍然是零值。

另外，Pool 中的元素可以被 Go 运行时自动移除。因此它适合降低临时对象的分配压力，不适合保存必须长期存在、不能丢失的数据。下面这张图把“取出—使用—清理—归还”的责任放在调用方一侧。

二、Get 以后不要直接相信旧字段

推荐给池中对象定义一个小而明确的重置方法。业务代码每次 Get 后先做一次初始化，或者通过构造函数式的辅助函数完成初始化。这样即使对象来自上一次调用，当前调用也不会依赖偶然的残留状态。

package main

import (
    "fmt"
    "sync"
)

type WorkItem struct {
    RequestID string
    Count     int
    Payload   []byte
}

func (w *WorkItem) Reset() {
    // 只保留底层容量，清掉长度，避免下一次看到旧字节。
    w.Payload = w.Payload[:0]
    // 标量字段必须显式归零，不能依赖 Pool 返回新对象。
    w.RequestID = ""
    w.Count = 0
}

var itemPool = sync.Pool{
    New: func() any {
        // New 只负责提供类型正确的初始对象。
        return new(WorkItem)
    },
}

func acquire() *WorkItem {
    item := itemPool.Get().(*WorkItem)
    // Get 后再次 Reset，让“新建”和“复用”走同一个入口。
    item.Reset()
    return item
}

func main() {
    item := acquire()
    item.RequestID = "req-42"
    item.Payload = append(item.Payload, []byte("temporary")...)
    fmt.Println(item.RequestID, string(item.Payload))
    item.Reset()
    itemPool.Put(item)
}

这里的关键点不是 New，而是 acquire 在 Get 后仍然调用 Reset。因为 New 只会在 Get 没有可返回对象时执行；一个已经被 Put 过的对象不会再次经过 New。

三、Put 前清理，避免旧数据和大引用被带回池

更常见的错误发生在归还阶段：业务函数提前返回、某个分支忘记清空字段，或者只把切片长度设为零却继续保留一个很大的底层数组。下一次使用时，旧字段可能影响逻辑，过大的底层引用也可能让暂时不用的内存继续被对象持有。

func handle(payload []byte) error {
    item := acquire()
    defer func() {
        // 无论后续返回 nil 还是 error，都先清理再归还。
        item.Reset()
        itemPool.Put(item)
    }()

    item.RequestID = "request-local"
    item.Payload = append(item.Payload, payload...)
    if len(item.Payload) == 0 {
        // 这个错误路径也会经过 defer，避免对象带状态回池。
        return fmt.Errorf("empty payload")
    }
    item.Count = len(item.Payload)
    return nil
}

如果对象的切片可能暂时持有数百 KB 甚至更大的底层数组，可以在重置时设置一个容量上限：容量过大就把切片断开，让对象不再保留这块大数组；容量较小时则保留空间，继续发挥 Pool 降低分配的作用。

const maxReusablePayload = 64  maxReusablePayload {
        w.Payload = nil
    } else {
        w.Payload = w.Payload[:0]
    }
    w.RequestID = ""
    w.Count = 0
}

四、为什么 Get 可能拿到旧对象，甚至返回 nil

官方文档明确说明，Get 取出的对象不应与之前 Put 的对象建立固定对应关系；Pool 可以选择忽略现有池内容，把它当作空池处理。没有可用对象且 New 为空时，Get 就会返回 nil。

因此类型断言前要确认是否配置了 New。如果对象池允许 nil，应该在获取函数里统一兜底，不要让业务代码在多个地方重复处理。

func acquireSafely() *WorkItem {
    value := itemPool.Get()
    if value == nil {
        // 没有 New 时的兜底分支，避免 nil 断言引发 panic。
        return new(WorkItem)
    }
    item, ok := value.(*WorkItem)
    if !ok {
        // Pool 内只应放入同一种对象；类型不符时立即拒绝。
        panic("unexpected object in WorkItem pool")
    }
    item.Reset()
    return item
}

五、哪些对象不适合放进 sync.Pool

可以用三个问题快速判断：对象是否只是临时工作区？丢掉它是否不会影响业务正确性？归还前能否彻底清理内部状态和外部引用？只要其中一个答案是否定的，就不应该仅为了减少分配把它放进 Pool。

六、实践中的检查清单

1. Get 后是否能把标量字段、切片长度和引用字段恢复到明确状态？
2. 所有返回路径是否都经过清理和 Put，尤其是错误分支？
3. 是否把过大的底层数组或敏感数据引用断开了？
4. 是否处理了 Get 返回 nil 的可能性？
5. Put 后是否仍有代码持有并使用同一个对象？如果有，说明归还时机过早。

一句话总结：sync.Pool 能帮你复用“可丢弃的临时对象”，但不会替你管理业务状态。把重置方法做成对象的一部分，在 Get 后建立状态、在 Put 前清理状态，并用 defer 覆盖错误路径，才能避免复用对象把旧数据带到下一次调用。

常见问题

sync.Pool 会保证 Put 后下一次 Get 取到同一个对象吗？

不会。Get 可能忽略池、从其他位置取对象，也可能返回 nil 或调用 New。代码应依赖对象契约，而不是依赖实例身份。

只把切片改成 [:0] 就算清理完成了吗？

不一定。它只清空长度，不会清掉底层数组中的字节；如果对象后续会暴露底层数组或保存敏感内容，需要覆盖数据或直接断开引用。同时还要清理其他字段。

可以在 Put 之后继续读取对象吗？

不可以把它当作自己的对象继续使用。Put 后所有权已经交回池，其他 goroutine 可能取走并修改它；需要继续使用时，应在 Put 前复制出需要的数据。