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

[matytan]

实现内存池用于对切片对象进行复用，减少内存分配次数 Mempool 是一个内存池库，用于在处理字节缓冲区时减少分配并提高性能。 https://github.com/matyle/mempool

[yulon]

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

[hopingtop]

@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 了

[bv]

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

[yulon]

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

[matytan]

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

[matytan]

@hopingtop 是的

[matytan]

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

[matytan]

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