Go sync.Pool 资源没有释放为什么

sync.Pool 的 Put 表示对象可以再次使用，不表示立即释放内存，更不会替你关闭文件、连接等外部资源。遇到“归还后资源没释放”，先分清是缓冲区仍保留容量、其他引用仍持有数据，还是外部句柄根本没有执行 Close。三种情况需要不同处理。

官方文档：https://pkg.go.dev/sync#Pool

把模式命名为临时对象复用

把 sync.Pool 看成临时对象的复用机会，更容易理解它的边界：某个请求用完缓冲对象后，允许后续请求借用已有分配。对象保留一段时间，本来就是减少重复分配的手段。池内条目可以在没有通知的情况下被移除，因此业务既不能要求它立即消失，也不能要求下次一定取回它。

假设一批导出请求偶尔生成大内容，结束后进程内存仍高。这个现象本身不能说明发生了泄漏。需要先看缓冲对象的长度和容量：bytes.Buffer.Reset 会清空可见内容，但保留底层存储供以后写入。长度变成零，不代表原来的容量同时归零。

识别需要复用的压力

这个模式适合短期、可重建、没有外部关闭义务的对象，并且分配开销确实值得减少。判断重点不是“每次都能复用”，而是即便池为空、Get 走到 New，功能也仍然正确。

如果对象必须始终存在、总数必须严格受控，或者每个对象都有明确的销毁回调，需求已经超出了临时复用。连接池、文件句柄池等通常需要容量、借还、健康检查与关闭语义，不应只换成 sync.Pool 就认为生命周期完整。

还有一种不合适的压力是输入尺寸高度离散。常规请求只需很小缓冲，极少数请求却扩容很多；若归还规则毫无筛选，常规请求就可能接手远超自身需要的容量。此时应先定义允许保留的单个对象大小，再讨论复用收益。

实现有容量门槛的缓冲区归还

下面以字节切片包装对象为例。归还时，小容量对象重置长度后复用，大容量对象从包装中解除引用，再保留这个轻量包装。示例门槛 64 KiB 只说明策略，不能作为所有服务的推荐值。应根据实际请求尺寸、并发量和内存预算决定。

package scratch

import "sync"

const maxRetained = 64  maxRetained {
        b.data = nil // 放弃大数组的这一个引用，不承诺立即回收
    } else {
        b.data = b.data[:0]
    }
    buffers.Put(b)
}

// Join 返回独立结果，调用方不会持有已归还的池内数据
func Join(parts ...[]byte) []byte {
    b := acquire()
    defer release(b) // 正常返回路径统一归还一次
    for _, part := range parts {
        b.data = append(b.data, part...)
    }
    result := make([]byte, len(b.data))
    copy(result, b.data) // 拷贝用于分离返回值和复用存储
    return result
}

这个实现刻意隐藏了借还接口，外部只能取得独立的结果。复制会产生结果分配，这是一项明确代价：它换取调用方继续持有结果时的独立所有权。如果调用方能在借用期间同步消费数据，也可设计受控的回调接口减少结果复制，但必须禁止回调保存底层切片供以后使用。

容量门槛只限制单个被保留的数组，不限制池内对象数量，更不限制所有正在使用的缓冲区。高并发仍可能同时持有许多小对象。需要严格总体内存预算时，应另有并发与队列控制，不能把这个门槛误写成对象池总上限。

用反例识别资源与引用错误

归还对象后返回其底层切片。例如返回 b.data，同时 defer release(b)。返回值与池内对象共享底层数组；下一位借用者写入后，旧结果可能改变。即使没有并发，也可能发生数据串用；有并发时还可能出现竞争。上例通过复制明确结束共享。

同一对象归还两次。池的并发安全不等于业务对象可以被多个借用者同时修改。借用结束后应只归还一次；归还后不得继续读写，除非对象自己有另行定义的同步协议。

把文件或连接塞进池，期待被移除时自动 Close。Pool 没有条目移除通知或逐个销毁接口，无法承诺资源关闭时机。外部句柄必须由资源所有者显式管理；是否复用、何时关闭和关闭失败怎么办，都应有可追踪的路径。

只清长度，不清对象引用。包装结构如果还保留请求上下文、结果对象或大型请求数据，下一次复用前这些引用就可能继续持有对象。应在归还处逐项清理不应跨请求保留的字段。切片元素含指针时，还需要考虑底层数组里原有元素的引用，而不只是把长度截短。

理解复用的后果和观察口径

排查时先固定负载范围，分别记录对象创建、借用、归还和容量分布。创建次数减少只说明复用可能起作用，不直接证明延迟更低；归还次数正常也不能证明不存在外部别名。不要依赖 Put 与下一次 Get 必定一一对应来推断所有权。

再把内存观测拆开：累计分配、当前仍存活的堆对象、运行时保留的空间，以及进程物理内存是不同指标。堆对象具备回收条件，不代表操作系统观察到的内存数字马上下降。Go 官方 GC 指南也区分虚拟地址空间和物理内存，不能拿单个进程数字直接给出泄漏结论。

若要验证容量筛选是否适合业务，可在读者自己的环境中比较相同输入下的对象尺寸分布、活跃堆和延迟，同时控制请求并发。本文没有运行这些实验，也没有给出吞吐或节省比例。不要把“调用一次 GC 后变化了”当成可依赖的清池协议。

切断大数组引用还存在两个限制：其他别名可能继续持有数组；归还前的内容也不会因此被安全擦除。Reset 和置 nil 都不是敏感数据擦除承诺。对不允许跨请求保留的数据，应先明确安全与生命周期要求，再决定是否进入复用模式。

按判断清单决定是否保留对象池

Put 后为什么内存没有马上下降？复用会保留对象，底层数组也可能仍有其他引用；内存回收与归还不是同一个动作。

bytes.Buffer.Reset 能释放大容量吗？不能以此保证释放，它保留底层存储。可以在归还策略中按 Cap 判断是否放弃该缓冲对象，或采用上例明确的引用重置。

能否循环 Get 到空来关闭所有条目？不能依赖这种方式。Get 的选择和池内条目保留都没有所需保证，配置了 New 时也不是简单的取空信号。

文档入口：https://pkg.go.dev/bytes#Buffer.Reset；内存观察背景：https://go.dev/doc/gc-guide。最终应把复用与销毁分别设计：允许保留的临时内存交给复用策略，需要确定关闭的资源交给明确的所有者。