Go sync.Pool 怎样判断对象复用是否合适

在 Go 服务里看到大量临时 bytes.Buffer、编码器或小型工作对象时，很多人会马上想到 sync.Pool。但“能复用”不等于“适合放进池”。判断标准其实很窄：对象必须是临时的，丢失后可以重新创建；复用能减少高频分配；归还前还能把业务状态和外部引用清理干净。

如果对象消失不会影响正确性，而且它在并发请求之间会被高频、短暂地重复使用，sync.Pool 才值得尝试。它不是稳定缓存，也不保证下一次 Get 拿回上一次 Put 的对象。

先判断对象是不是临时的

sync.Pool 的定位是保存“已分配但暂时不用”的临时对象。运行时可以在没有通知的情况下移除池中任何元素；如果池是唯一引用，对象也可能直接被回收。因此，池里的对象不能承担会话状态、配置快照、连接、锁、文件句柄或必须长期保留的数据。

一次日志格式化、请求编码、短暂的字节拼接，通常符合这个条件：本次使用结束后，下一次请求拿到新对象也能得到同样的业务结果。相反，如果对象里保存着必须命中的缓存、递增序号或未提交的业务状态，就不应把它交给 sync.Pool。

用 New、Get、Put 组成最小复用闭环

最小实现通常把池声明为包级变量，让多个并发请求共享它。New 负责池为空时创建对象；Get 取出一个任意对象；使用者先清空，再写入当前请求内容；最后只有在对象仍然适合复用时才 Put 回去。

package logline

import (
    "bytes"
    "io"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        // 返回指针便于直接放入接口，避免把整个 Buffer 复制进接口。
        return new(bytes.Buffer)
    },
}

func WriteLine(w io.Writer, level, message string) error {
    // Get 可能返回 nil，所以 New 必须覆盖“池为空”的情况。
    buf := bufferPool.Get().(*bytes.Buffer)
    // 清掉上一次请求留下的内容，避免跨请求串数据。
    buf.Reset()
    buf.WriteString(level)
    buf.WriteString(": ")
    buf.WriteString(message)

    _, err := w.Write(buf.Bytes())
    // 当前示例没有把 Bytes 返回给调用方，写完后才归还。
    bufferPool.Put(buf)
    return err
}

这里的关键不是把代码写成“有池就一定更快”，而是让对象的所有权清楚：WriteLine 在写入完成前不能归还 buf，调用方也不能在归还后继续读取它的内容。标准库文档还说明，Pool 可以被多个 goroutine 并发使用，但不能在第一次使用后复制。

把清空和容量边界写进归还前

Reset 只会把逻辑长度清零，不代表底层容量一定适合长期留在池里。某次异常大的请求可能让一个缓冲区持有很大的底层数组；如果它被无条件放回池，后续普通请求就可能间接保留这块内存。更稳妥的做法是把容量上限作为归还条件。

const maxReusableCapacity = 64 * 1024

func putBuffer(buf *bytes.Buffer) {
    // 先解除当前使用者对内容的依赖，再判断是否保留容量。
    if buf.Cap() > maxReusableCapacity {
        // 大对象直接丢弃，让运行时自行回收，不把异常峰值带回池。
        return
    }
    // Reset 保证下一位使用者看不到上一位使用者的内容。
    buf.Reset()
    bufferPool.Put(buf)
}

如果代码把 buf.Bytes() 保存到了异步任务、响应对象或日志队列，就不能在任务真正结束前归还。因为切片仍然指向同一块底层数组，下一次使用池中对象时可能覆盖它。对于这类场景，要么复制需要异步保留的数据，要么延后归还，不能只依赖 Reset。

哪些对象通常不值得池化

第一个反例是短生命周期对象的专用空闲链表。对象只在一个短命组件内部使用，调用次数又不高时，维护池的接口和清理成本可能比重新分配更复杂。官方文档也明确指出，这类情况下由对象自己维护空闲链表可能更合适。

第二个反例是大而不稳定的对象。池没有“按容量自动淘汰到业务期望值”的承诺，峰值请求可能把大数组留在池里一段时间。对这类对象，更适合设置容量门槛，或者使用业务层明确管理的缓存。

第三个反例是需要确定性生命周期的资源，例如网络连接、数据库事务、文件描述符和带锁状态的对象。它们需要显式关闭、提交、回滚或加锁顺序，不能把“可能被清空”当成生命周期管理。

不要把 Get 的偶然命中当成缓存协议

Get 会选择一个任意对象，也可以把池当成空的处理。即使某个对象刚刚 Put，下一次 Get 也不保证拿到它。代码因此必须对“新建对象”和“复用旧对象”一视同仁，并在每次取出后完成必要的初始化。

type Work struct {
    Name  string
    Items []string
}

var workPool = sync.Pool{
    New: func() any {
        // New 只提供可重新创建的临时工作对象。
        return new(Work)
    },
}

func acquireWork() *Work {
    work := workPool.Get().(*Work)
    // 不依赖 Get 的来源，统一清理字符串和切片长度。
    work.Name = ""
    work.Items = work.Items[:0]
    return work
}

func releaseWork(work *Work) {
    // 归还后不能再读写 work，调用者必须先完成所有使用。
    workPool.Put(work)
}

这也是为什么 sync.Pool 更像“降低分配压力的机会”，而不是应用层的对象租约系统。业务逻辑不应依赖命中率、对象数量或某次取回的身份。

用基准和分配数据决定是否保留

判断池化是否有价值，至少要比较三组结果：不使用池、使用池但不做容量控制、使用池并做清理与上限控制。测试负载要包含常规请求、并发峰值和少量超大输入，否则很容易只测出理想路径。

func BenchmarkWriteLine(b *testing.B) {
    // 让基准覆盖相同的输入，便于比较是否减少了分配。
    payload := bytes.Repeat([]byte("x"), 256)
    b.ReportAllocs()
    for i := 0; i 

观察重点是每次操作分配次数、分配字节数、延迟尾部和进程在空闲后的内存表现。Go 的性能建议把 sync.Pool 放在减少临时对象分配的工具箱里，同时提醒错误使用会引入类似 use-after-free 的数据复用问题。若池化只让代码更复杂，却没有在真实负载中改善这些指标，就应删除它。

一张表做最后判断

结语

Go sync.Pool 最适合的不是“所有昂贵对象”，而是高频、短暂、可丢弃、可重新初始化的临时对象。把 New、Get、Put 写出来只是第一步；真正的边界在于归还前是否清掉状态、是否解除外部引用、是否拦住异常容量，以及池化收益能否被基准数据说明。

相关问题

• sync.Pool 会保证对象一直存在吗？不会，池中对象可能被运行时自动移除，业务逻辑不能依赖它的存在。
• 为什么示例通常把 New 写成返回指针？指针更适合在接口中传递，也避免把可变对象按值复制。
• bytes.Buffer 归还前一定要 Reset 吗？如果仍可能被下一位使用者读取，必须先清空；若对象完全丢弃则无需为了归还而 Reset。