Go sync.Pool 怎样复用临时对象而不保存业务状态

如果我要在 Go 里反复创建短生命周期的缓冲区，通常会先考虑 sync.Pool；但我会把它当作“可随时失去的临时对象集合”，不会把订单状态、用户会话、配置快照或任何必须找回的数据放进去。Pool 可以在多个 goroutine 间安全使用，却不承诺对象一直存在、按顺序返回，甚至允许一次 Get 直接表现为空。

正确的边界是：业务状态由调用方或持久化结构负责，Pool 只负责降低临时对象反复分配的压力。对象从 Pool 取出后由当前调用方独占，使用完必须清理并在没有其他引用后再放回；即使对象被自动丢弃，业务也应该照常正确工作。

Go 官方标准库地址：https://pkg.go.dev/sync#Pool

• 适合放：短暂使用、可以重新创建、跨请求形状相近的缓冲对象。
• 不适合放：必须持久保存的业务状态、带租约的资源、依赖固定顺序的任务或需要精确容量控制的对象。
• 关键动作：取出后初始化，写入前确认所有权，交还前清理，结果需要保留时先复制。

临时对象和业务状态怎样分层

Pool 的价值不在于“保存更多对象”，而在于让已经分配过、暂时不用的对象有机会被下一次工作复用。官方文档把它定义为临时对象集合，并明确说明其中的项目可能在任意时刻被自动移除；如果 Pool 是唯一引用，对象甚至可能被回收。因此，Pool 的内容不能成为业务正确性的唯一来源。

我会把数据分成两层：请求参数、业务判断和最终结果属于不可丢失的业务层；*bytes.Buffer、临时编码空间和可重建的 scratch slice 属于可回收的临时层。临时层可以帮助业务层工作，但不能反过来承担业务层的持久语义。

这条边界也解释了为什么 Pool 不是普通缓存。缓存通常要讨论命中、过期、容量、淘汰和一致性；Pool 只承诺“有机会复用”，不承诺命中。一个请求即使永远取不到之前放入的对象，也不应该丢失业务数据。

用 New、Get、Put 复用一个缓冲区

一个常见的最小组合是让 New 返回指针类型。指针既能避免把大对象复制进接口值，也方便调用方在取出后直接调用方法。每次拿到对象后，都应该把它当作可能带有旧内容的容器，先恢复到本次任务需要的初始状态。

package main

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

var bufferPool = sync.Pool{
    New: func() any {
        // 只创建可重建的临时缓冲区，不把业务状态放进 Pool。
        return new(bytes.Buffer)
    },
}

func renderLine(name, value string) string {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 取出的对象可能带着上一次内容，复用前先清空。
    buf.Reset()
    buf.WriteString(name)
    buf.WriteByte('=')
    buf.WriteString(value)

    // 先复制出独立字符串，再交还仍被 buf 持有的底层数组。
    result := buf.String()
    bufferPool.Put(buf)
    return result
}

func main() {
    // 业务结果保存在 result，不依赖 Pool 继续保留缓冲区。
    result := renderLine("mode", "preview")
    fmt.Println(result)
}

这里的 result := buf.String() 表达了一个重要边界：返回值必须脱离临时缓冲区的生命周期。若直接把 buf.Bytes() 返回给调用方，后续复用或清空同一个 Buffer 就可能改变调用方看到的内容；如果确实要返回字节切片，应先复制。

示例把 Put 放在函数末尾，是为了让“使用结束”和“交还”紧挨着出现。更复杂的函数可以用 defer 统一释放，但必须先保存需要返回的独立结果，不能让延迟交还早于结果复制。

交还前清理，并结束当前调用方的独占使用

官方文档保证 Pool 自身可以被多个 goroutine 同时使用，但这不等于同一个缓冲对象可以被多个 goroutine 同时写。Get 把对象交给当前调用方后，我会把它视为“临时独占”；在调用方仍然使用它、或者另一个 goroutine 还持有它的引用时，不能调用 Put。

func encodeFields(fields []string) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 无论上一次留下什么内容，本次编码都从空缓冲区开始。
    buf.Reset()

    for _, field := range fields {
        // 使用分隔符表达字段边界，输入数据本身仍由调用方管理。
        if buf.Len() > 0 {
            buf.WriteByte('|')
        }
        buf.WriteString(field)
    }

    // 复制出独立切片，避免 Put 后底层数组继续被改写。
    encoded := append([]byte(nil), buf.Bytes()...)
    buf.Reset()
    bufferPool.Put(buf)
    return encoded
}

清理有两层含义：第一层是逻辑清理，例如 Reset 让下一次使用看不到旧的长度和内容；第二层是引用清理，例如把不再需要的大切片、指针或错误上下文从自定义对象字段中断开。后者不能机械地套在所有类型上，应按对象结构决定，目标是避免临时容器意外长期保留大对象。

如果把一个带业务字段的结构体直接放进 Pool，就要特别警惕“清空不完整”。例如租户 ID、权限标记、请求头和上一次请求的错误信息，只要有一项遗漏，就会把临时复用变成跨请求状态污染。更稳妥的做法是让 Pool 只负责专门的缓冲类型，业务数据留在函数参数和返回值里。

Get、Put 和 New 各自保证什么

我在评审 Pool 代码时，会把三个 API 的保证拆开看：New 是取不到对象时的创建策略，Get 是一次任意选择，Put 是把当前调用方已经结束使用的对象交还。它们共同形成复用机会，却没有形成一个可靠的持久队列。

文档还说明，Pool 中的对象可以无通知地被移除，Get 可以忽略 Pool 并把它当作空集合。这两个规则让 Pool 能在低负载时自然收缩，也决定了它不适合实现必须可靠取出的工作队列。

为什么不能把业务状态塞进 sync.Pool

下面这些做法表面上像是在“减少分配”，实际上把正确性绑定到了一个没有持久保证的容器上：把用户登录态放入 Pool 等待下一次请求取出；把未完成任务放入 Pool 期待按顺序消费；把数据库连接、文件句柄或带租约资源当作普通对象反复丢回去；把 Pool 里当前对象数量当作业务计数。

这些需求分别需要不同的所有权模型。会话状态要有明确存储和过期策略，任务需要队列或调度器，外部资源需要显式关闭和生命周期管理，计数需要原子操作或锁。Pool 的线程安全只覆盖 Pool 的取放动作，不会替你解决这些领域问题。

如果对象内部包含可变字段，也不能因为它从 Pool 取出就跳过同步。当前调用方独占一个对象时可以安全修改；一旦把指针共享给其他 goroutine，就必须按 Go 内存模型的要求使用 channel、锁或原子操作协调读写。

哪些场景适合 Pool，哪些场景应该换方案

我通常用三个问题做决定。第一，这个对象能不能在取不到时快速创建？第二，丢掉它会不会丢失业务信息？第三，归还前能不能明确结束所有引用？三个答案分别是“能、不会、能”，才接近 Pool 的适用区间。

Pool 也不是性能开关。它减少的是部分分配和垃圾回收压力，是否值得引入要看对象大小、调用频率、并发负载和代码复杂度。没有测量时，我会先保持普通分配写法，再用实际指标判断是否需要复用；不会为了让代码“看起来高性能”而给每个小对象加一个全局 Pool。

生产代码可以按这份清单收口

1. Pool 中的对象是否只是临时工作空间，丢掉后业务仍然正确？
2. New 是否返回了可安全初始化的对象，且没有依赖只执行一次？
3. Get 后是否先清除旧内容，并确认类型断言对应同一个 Pool 约定？
4. 结果是否已经复制，是否还有 goroutine、切片或闭包引用着待交还对象？
5. Put 前是否完成必要的逻辑清理，是否把业务状态和大对象引用断开？
6. 代码是否依赖命中、顺序、容量或对象身份？如果依赖，是否应该改用缓存、队列或状态结构？

最后可以把记忆点压缩成一句话：sync.Pool 复用的是“可以重新造出来的工作材料”，不是“必须保留下来的业务事实”。只要把业务结果先移出临时对象，再在所有权结束后清理并交还，Pool 才会成为可选的优化，而不是隐藏的状态来源。

Pool 里的对象一定会被下一次 Get 取到吗

不一定。Get 可以把 Pool 当作空集合，Pool 中的对象也可能在任意时间被自动移除。代码必须准备好重新创建。

Put 之前需要调用 Reset 吗

通常应该清理会影响下一次使用的状态。对于 bytes.Buffer，Reset 可以清除长度；若对象还有其他字段或引用，还要按类型补充清理。

sync.Pool 能代替并发队列吗

不能。Pool 不保证先进先出、可靠保留或精确交付；需要任务不丢失、顺序和背压时，应使用 channel 或专门队列。

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