sync.pool存在的坑以及解决方案

1. 内存泄漏

取出来的 bytes.Buffer 在使用的时候，我们可以往这个元素中增加大量的 byte 数据，这

会导致底层的 byte slice 的容量可能会变得很大。这个时候，即使 Reset 再放回到池子

中，这些 byte slice 的容量不会改变，所占的空间依然很大。而且，因为 Pool 回收的机

制，这些大的 Buffer 可能不被回收，而是会一直占用很大的空间，这属于内存泄漏的问

题。

解决：

在put时先判断内存大小，再决定是否要放回池子，比如fmt.print() 优化方案：

2. 内存浪费

除了内存泄漏以外，还有一种浪费的情况，就是池子中的 buffer 都比较大，但在实际使用

的时候，很多时候只需要一个小的 buffer，这也是一种浪费现象。接下来，我就讲解一下

这种情况的处理方法。

要做到物尽其用，尽可能不浪费的话，我们可以将 buffer 池分成几层。首先，小于 512

byte 的元素的 buffer 占一个池子；其次，小于 1K byte 大小的元素占一个池子；再次，

小于 4K byte 大小的元素占一个池子。这样分成几个池子以后，就可以根据需要，到所需

大小的池子中获取 buffer 了。

在标准库 http/server.go就有相关例子