gnet没有“Gnet-Pool”组件，其内存复用依赖三个解耦模块：bytebufferpool管理[]byte切片、ants管理goroutine、ringbuffer.Pool自研复用*RingBuffer对象，三者职责分明、无统一聚合入口。
gnet 没有叫 “Gnet-Pool” 的内置内存池组件——这个名字不存在于源码、文档或任何官方发布物中。 它是开发者对 gnet 内存复用机制的误称，容易导致配置错、依赖错、甚至调试时查不到对应代码。
为什么搜 Gnet-Pool 会找不到东西？
gnet 的内存复用完全基于三个明确、解耦、可独立启用/替换的外部或自研池化模块：
-
bytebufferpool：来自github.com/valyala/bytebufferpool，管理[]byte切片，用于协议解析、序列化响应等临时字节操作 -
ants：来自github.com/panjf2000/ants，管理 goroutine 实例，和内存无关，但影响整体资源水位 -
ringbuffer.Pool：gnet 自研的*RingBuffer对象池，在pkg/pool/ringbuffer下，复用缓冲区结构体本身，不涉及底层字节内存
没有统一入口、没有聚合类型、没有 GnetPool 或 Gnet-Pool 这样的 struct 或包名。所有“池”的使用都是显式调用各自 Get()/Put() 方法。
bytebufferpool.Get() 必须配对 Put()，否则内存泄漏
这是最常踩的坑：拿到 bytebufferpool.ByteBuffer 后只用、不还，会导致池内对象持续增长，最终退化为每次都 new，GC 压力飙升。
- 必须在 handler 返回前调用
buf.Put()（注意不是bytebufferpool.Put(buf)） - 若 buf 来自
bytebufferpool.Get()，则用buf.Reset()清空内容再Put()；若来自bytebufferpool.GetSize(n)，也一样 - 切勿把池中取出来的
buf.B（即[]byte）直接传给第三方函数并丢失控制权——一旦无法保证归还，就别从池里拿
RingBuffer 不是 deque，别试图头插尾删
很多开发者看到 inboundBuffer 和 outboundBuffer 都是 *RingBuffer 类型，又听说它“支持两端操作”，就误以为能像 container/list 那样做 PushFront 或 PopBack。
-
RingBuffer只暴露Write()和Read()，读写指针单向推进、自动绕回 - 已读数据不会被清除，只是读指针前移；空间是否可复用，取决于读写指针相对位置
- 没有
Len()返回“有效数据长度”，只有Readable() / Writable()，且结果受当前指针位置严格约束 - 若强行用
bytes.Buffer替换RingBuffer，会破坏零拷贝路径，性能断崖下跌
真正关键的点不在“有多少池”，而在“谁管哪层内存、何时归还、边界是否清晰”。bytebufferpool 管字节切片，ringbuffer.Pool 管缓冲区对象，ants 管执行流——三者职责分明，混用或跳过任一环节，都可能让优化失效。
