Go sync.Pool 怎样理解对象被回收的时机

我第一次认真使用 sync.Pool，是为了复用请求处理中反复创建的 bytes.Buffer。代码跑起来以后，最容易产生的误解是：既然我已经调用了 Put，下次 Get 就应该拿回同一个对象。实际上，Pool 更像一个允许运行时随时清空的临时物品架，而不是带保留承诺的缓存。

只要对象在业务上“丢了也能重新创建”，它才适合放进 sync.Pool。GC 可能在没有通知的情况下移除池中对象，Get 也可以直接返回空；正确的写法必须准备好重新创建，并且不能依赖对象一定跨 GC 留存。

官方资料：https://pkg.go.dev/sync#Pool

我遇到的困惑：Put 之后，对象到底能活多久

把一个临时对象放回 Pool 后，它有三种可能：很快被另一个 goroutine 取走；暂时留在 Pool 的内部缓存中，等待后续复用；在 GC 相关清理中被移除。如果 Pool 是对象唯一的引用，对象还可能随之变成可回收对象。这里的关键不是“GC 后必然清空”，而是“API 没有承诺对象必须保留多久”。

这也解释了我在压测中看到的现象：低并发时某个对象地址经常重复出现，高并发或 GC 频繁时重复率又下降了。重复出现是实现和负载共同造成的结果，不是 sync.Pool 的持久化契约。官方文档明确说，Pool 中的条目可以在任意时间自动移除，调用者不能根据上一次 Put 推断下一次 Get 的返回值。

GC 到来时，Pool 里的对象经历了什么

从概念上可以把 Pool 想成两层临时空间。当前周期里刚放入的对象在 primary cache；进入下一次 GC 周期前，运行时会把这批空间转成上一周期的 victim cache。更老的 victim cache 会被丢弃，新一轮 GC 又会重复这个过程。

因此，某个对象在一次 GC 后仍然有机会被 Get 取出，但这只能理解为“给对象一个短暂的复用机会”，不能写成“对象至少保存一个 GC 周期”。下一次 GC 可能清掉上一周期的 victim cache；即使没有发生 GC，Get 也可以选择忽略 Pool，把它当作空池处理。

Go 源码中的 poolCleanup 在 GC 开始、世界暂停的阶段执行清理：先丢弃旧的 victim cache，再把当前的 local cache 移到 victim cache。源码是解释实现的好材料，但业务代码不应该依赖这些内部数组、P 绑定或具体清理顺序；对外稳定的判断仍然只有一句：Pool 中的对象随时可能消失。

先把对象当成“可丢弃”，再设计 Get 和 Put

我现在写 Pool 代码时，会先问一个问题：如果 Get 返回新对象，功能是否仍然完全正确？如果答案是否定的，说明这里需要的是明确的缓存或所有权，而不是 Pool。如果答案是肯定的，才继续安排复用生命周期。

最小模式通常是 Get、Reset、使用、Put。Reset 要放在拿到对象之后，防止上一次请求留下的字节、错误状态或容量假设泄漏到这一次。

package main

import (
    "bytes"
    "fmt"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        // Pool 为空时创建新的临时缓冲区；创建失败不应影响业务正确性。
        return new(bytes.Buffer)
    },
}

func render(prefix, name string) string {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 清掉上一次使用残留的数据，避免跨请求污染输出。
    buf.Reset()
    defer bufferPool.Put(buf)

    fmt.Fprintf(buf, "%s: %s", prefix, name)
    // String 会复制出当前结果，之后缓冲区才能安全放回 Pool。
    return buf.String()
}

func main() {
    fmt.Println(render("user", "alice"))
}

这里的 defer 不是为了保证对象永远留在池里，而是为了保证这次函数调用结束时把暂时不用的对象归还。若中间新增了提前返回、错误分支或 panic 恢复逻辑，归还动作仍然集中在一个位置。

New、nil 和类型断言是三个必须面对的边界

设置了 New 以后，Get 在没有可用对象时会调用它；没有设置 New 时，空池可能返回 nil。这正是 Pool 生命周期语义落到代码里的地方：池空不是异常，而是正常分支。

type scratch struct {
    buf []byte
}

var scratchPool sync.Pool

func acquireScratch(size int) *scratch {
    value := scratchPool.Get()
    if value == nil {
        // 空池是允许的；按本次任务需要创建对象。
        return &scratch{buf: make([]byte, 0, size)}
    }

    item, ok := value.(*scratch)
    if !ok {
        // 类型不匹配时不要继续使用未知对象，直接恢复一个新对象。
        return &scratch{buf: make([]byte, 0, size)}
    }
    item.buf = item.buf[:0]
    return item
}

func releaseScratch(item *scratch) {
    if item == nil {
        return
    }
    // 只归还可重新初始化的临时对象，不把业务所有权放进 Pool。
    item.buf = item.buf[:0]
    scratchPool.Put(item)
}

如果使用固定类型的 New，类型断言可以更直接；如果 Pool 被封装在公共组件里，仍然要保持类型边界清楚。不要把一个带有请求身份、权限信息或外部资源句柄的复杂业务对象随手放进去，否则复用时很难证明状态已经被完整清理。

把 Pool 当作可丢弃资源，而不是缓存

我觉得判断是否使用 sync.Pool，比记住内部 GC 细节更有用。只看对象的业务属性：它是否临时、是否被多个独立请求复用、是否可以随时重新分配。如果必须保留、必须按 key 查询、必须在重启或 GC 后继续存在，就不应该把 Pool 当成解决方案。

还有一个容易忽略的取舍：Pool 不是“用了就一定更快”。如果对象很小、创建成本很低，维护复用路径、重置字段和增加测试的成本可能抵消收益。官方文档把 fmt 的临时输出缓冲区作为合适例子，因为它会随并发压力扩展，空闲后也允许收缩；这正是“可复用但不必保留”的典型。

最后用一句话记住生命周期

sync.Pool 只承诺提供一个并发安全的临时对象复用机会，不承诺对象的存活时间、命中率或跨 GC 可见性。把 Get 返回新对象视为常态，把 Put 看成“归还一个暂时不用的对象”，把 Reset 当成复用前的边界，就不会把实现细节误当成业务保证。

相关问题

• Pool 里的对象会在每次 GC 后全部消失吗？不一定。实现会给上一周期的对象一次短暂复用机会，但 API 不保证任何对象必须留下。
• Get 一定会返回 Put 进去的那个对象吗？不会。Get 可以返回任意池对象，也可以把池当作空池；设置 New 后还可能返回新建对象。
• 为什么 Put 前要 Reset？为了避免下一次使用读到上一轮留下的字节或状态；Reset 是业务正确性的边界，不是 GC 的替代品。
• Pool 能不能保存连接、事务或带权限的对象？除非能严格管理外部资源和全部状态，否则不建议。必须稳定保留或显式关闭的对象应有明确的生命周期管理。

官方实现参考：https://go.dev/src/sync/pool.go