分享一个自己 golang 的库，用于尽量不 GC 的内存池

buffer 的内存池。
没点进去之前我以为是变量的内存池，哈哈哈

提高性能？ 应该数据说一下。

为什么不用标准库里的 sync.Pool ... ...

看了下，只是 bytes.Buffer 的内存池，用途感觉不是很广; 而且也没有和 sync.Pool 对比的 benchmark

@vfs 嗯嗯准备做个 benchmark ，已经在业务中体现了，还没做 benchmark

@zdt3476 嗯嗯 用途不是很广，主要是防止多协程频繁 GC ，会做个 benchmark ，README 没有贴上我业务内存的对比图

@Mohanson 最开始业务里面就是用的 sync.pool 但是在大内存业务下，gc 会撑爆内存，后面使用了这个限制 gc

。。。解释下，为啥用了 sync.pool ，gc 会撑爆内存。。。

@kkhaike 本质上是 json 的序列化导致 makeslice 很大，使用 syncpool 并没有限制协程的 buffer 对象，来不及 gc 导致某一时刻峰值很大

我们也遇到 op 一样的问题，json 序列化会撑爆内存，就是因为 sync.Pool + json.Buffer 导致的。
当 99%的数据是小包 1%的数据突然来一个几十 MB 的大包，那么有可能后面 sync.Pool 里面的 buffer 都会变成几十 MB ，就会导致内存爆掉。

这个问题，Golang 有最新的提案和实现, 就是动态优化 buffer 的大小。 但是还没有合并！

相关 code 链接 https://go-review.googlesource.com/c/go/+/471200

@hopingtop https://github.com/valyala/bytebufferpool 可以用 fasthttp 作者写的这个，如果少数 buffer 特别大会直接丢掉对应的 buffer 。

我才看了 op 的代码，如果你真的想实现 mem 的高效利用，可以参考上面的链接实现或许会更好！

目前 mempool 有点问题就是，限制了上限，但是释放不了下限，没有考虑到 release 机制， 最终还是可能会把所有 buffer 都撑大！

@Trim21 #11 场景比较特殊，当前绑定了 json 序列化，后期准备改成 pb 一劳永逸

@hopingtop 包装下 sync.Pool, 把大包扔掉就好了

@Nazz #14 唉，encode/json 底层实现用了 全局 sync.Pool ，包括 json-iterator 也是类似实现，所以包不了。 如果 json-iterator 提供设置 自定义的 pool 就好了，可惜也没有

@hopingtop 使用 json.Encoder/Decoder 就可以自己管理 buffer pool 了

@Nazz #16 我确定是我表示不清楚，还是太久了，你忘记了，所以我们说的不是同一个东西，你可以再去看看代码
```go
// NewEncoder returns a new encoder that writes to w.
func NewEncoder(w io.Writer) *Encoder {
return &Encoder{w: w, escapeHTML: true}
}

// Encode writes the JSON encoding of v to the stream,
// followed by a newline character.
//
// See the documentation for Marshal for details about the
// conversion of Go values to JSON.
func (enc *Encoder) Encode(v any) error {
if enc.err != nil {
return enc.err
}

e := newEncodeState()
defer encodeStatePool.Put(e)
```
```go
var encodeStatePool sync.Pool

func newEncodeState() *encodeState {
if v := encodeStatePool.Get(); v != nil {
e := v.(*encodeState)
e.Reset()
if len(e.ptrSeen) > 0 {
panic("ptrEncoder.encode should have emptied ptrSeen via defers")
}
e.ptrLevel = 0
return e
}
return &encodeState{ptrSeen: make(map[any]struct{})}
}
```
核心消耗内存的地方是 encodeState

@hopingtop #17 '我确定是' -> '我不确定是'

@hopingtop 是我想得太简单了😂

不懂为什么会爆，sync pool 既然是循环使用的那 pool 里面的对象数量应该不会很多才对。考虑到 json 的普遍性如果真有问题应该有很多相关 issues 才对，能不能放几个

原来 JSON 序列化会爆内存，怪不得，之前有个奇葩甲方一定要我直接拿 JSON 当数据库，然后占内存严重，我就又偷偷改成普通数据库

@matrix1010 #20 其实网上有比较多的案例，只是大部分情况下，遇不到。大多数场景，我们所产生的数据包 浮动是有限的，所以里面的 buffer 大小就算扩容也有限，本身来说 sync.Pool 是会回收，只是比较慢，通常来说一般要经过 2-3 个 GC 标记确认不用了才回收，但是这里一般流量较大，才会使用到 sync.Pool 的场景，所以可能导致一直回收不了。

第二点就是 我们是容器部署，容器层限制了 2G 的内存使用量。 但是这个容器限制对于 Go 语言是感知不到的。在 go >1.19 版本,才出现有一个参数配置好像是 GOMEMLIMIT=xx ，告知 Go 我限制了内存。这个时候感到分配压力，GC 才会频繁活动！

但是我们恰巧是 <1.19 , 我们物理机本身是 32G 内存，所以 Go 感觉内存是杠杠够的，但是 Docker 的 Limit ，导致在 Docker 层直接把进程 Kill 了

@yulon 你这应该跟池化关系不大，可能就是 JSON 太多太大，又需要常驻内存，导致内存占用高。

@bv 是运行好几天之后才爆的，重开程序就低得一批，内存里常驻的数据缓存尺寸固定，怎么可能是太多太大了？

@yulon 仔细看我的代码实现，会释放

@hopingtop 是的

@hopingtop 谢谢，其实我在 put 的时候做了一点 trick 的释放和重建，目前够用，后期我会结合你这个代码优化

@matrix1010 如果不重用，来不及 gc 就会爆炸的