sync.Pool 降低 GC 压力，但别让它变成内存隐患

最近排查一个 Go 服务的内存问题时，发现一个有趣的现象：明明用了 `sync.Pool`，按理说能减轻 GC 压力，结果内存占用却居高不下，甚至出现了疑似内存泄漏的报警。翻看代码，`sync.Pool` 用得倒是挺勤快，但细看之下，问题恰恰出在对它的“过度信任”上。

`sync.Pool` 的设计初衷是复用临时对象，减少堆分配，从而降低 GC 扫描和回收的开销。这一点在高并发、高频率创建且生命周期极短的对象场景下非常有效，比如解析请求、序列化缓冲等。它内部通过 `Get` 和 `Put` 来借还对象，而且每次 GC 发生时，池子里的对象会被清理掉，所以从语义上它并不保证对象一定会被复用，也不适合用来做连接池或长期缓存。很多人对第一点很清楚，却容易忽略第二点和它的副作用。

重点来了：`sync.Pool` 本身并不能保证一定帮你减少内存占用，它只是把“分配”变成了“复用”，但复用的对象仍然占用着内存。如果你把每个对象的尺寸很大，或者把对象长时间留在池子里（其实 GC 会清），或者在多个 goroutine 间大量 `Put` 但对方并不 `Get`，那么这个池子实际上就变成了一个未释放的内存仓库。尤其在高峰期，为了应对并发，池子会不断扩充对象数量，高峰过后却不会自动收缩（除了 GC 清空），如果业务代码又把对象 `Get` 回来而不放回，甚至放回了却没重置状态，那不仅内存居高不下，还会产生数据污染，造成更隐蔽的 bug。

另一种常见误区是把 `sync.Pool` 当成“无限缓存”。有些同学觉得只要往池子里塞对象，就能随便取，甚至用池子来保活一些长生命周期的东西。但仔细想想，GC 一到，池子就被清空，你的“保活”根本没有意义，反而白白消耗了管理开销。更糟糕的是，很多人没有注意 `New` 字段的设置——如果没有设置 `New`，`Get` 在池空时会返回 `nil`。一旦代码没判断 nil，直接使用，轻则空指针，重则在并发压力下频繁触发 panic，这才是真正的隐患。

要让 `sync.Pool` 真正发挥价值，我的建议是遵守几个原则：第一，它只用于高频创建、低频存活的对象，比如临时字节缓冲区、结构体切片，千万别把连接、文件句柄等需要真实释放的资源丢进去；第二，`Put` 前务必把对象重置到“零值”状态，避免脏数据串味；第三，合理设置 `New` 函数，并让池子的大小由业务并发度自然决定，不要手动做无意义的 “预热”；第四，也是最重要的一点，监控内存曲线和 GC 停顿，如果发现用了池子反而 RSS 上涨，那就该警惕是不是池中对象过大或 `Put` 过多却没被取走。

我见过一个典型的反面案例：某个网关把每个请求的上下文结构体塞进 `sync.Pool`，这个结构体里有个 1 MB 的预分配切片。并发峰值时，池子里攒了几十个这样的对象，GC 虽然能清掉一部分，但在 GC 周期之间，这些巨物一直挂在堆上，直接导致内存暴涨——你说这是 GC 的锅还是 `sync.Pool` 的锅？其实是用的人把“复用”误解成了“常驻”。

总而言之，`sync.Pool` 是一把锋利的刀，能帮你减少 GC 压力，但也可能变成内存隐患。它的关键不在于“用得越多越好”，而在于“用得恰到好处”。每次使用前，先问自己三个问题：这个对象真的适合复用吗？放回后状态可预期吗？池子里的对象大小和数量是否可控？如果答案不确定，那么显然，你还没准备好使用它。哪怕技术上它不是内存泄漏，这口锅也是实实在在的。