ByteBuf 内存池

Difficulty: Advanced
Status: Stable
Last reviewed: 2026年8月

This content is not available in your language yet.

ByteBuf 内存池解决两个问题：减少频繁堆外分配和释放的系统成本，以及把 I/O 缓冲区的生命周期从 GC 转为显式引用计数。Netty 4.2 同时保留经典 PooledByteBufAllocator，并引入 AdaptivePoolingAllocator，两条路径需要分开理解。

先给答案：ByteBuf 内存池把“分配成本”换成“生命周期管理成本”

高频网络 I/O 如果每次读写都创建新的堆对象或直接缓冲区，会把延迟和 GC 压力推给分配器。池化 ByteBuf 预先切分 Chunk、Page 和 Subpage，并通过线程本地缓存优先复用最近释放的内存，从而降低分配和回收频率。

但池化并不是免费内存：引用计数、跨线程转移、容量扩展和泄漏检测都变得更重要。一个 Buffer 看起来“用完了”并不代表引用数已经归零；如果 Handler 转交了它，就必须明确下一个所有者，否则优化分配得到的收益会被泄漏或 use-after-release 抵消。

经典路径

PooledByteBufAllocator
   │ threadCache.get()
   ▼
PoolThreadCache
   ├─ small cache -> PoolSubpage
   ├─ normal cache -> PoolChunk
   └─ miss -> PoolArena -> PoolChunkList -> new PoolChunk

PooledByteBufAllocator#newDirectBuffer 先取当前线程的 PoolThreadCache，再交给 direct PoolArena，坐标为 buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java:397-408。

PoolArena#allocate 先把请求映射为 sizeIdx，小对象走 subpage，普通对象走 normal allocation，超大对象绕过缓存，坐标为 buffer/.../PoolArena.java:129-147。普通分配失败后从不同利用率的 PoolChunkList 尝试，最后新建 Chunk，坐标为 PoolArena.java:206-223。

PoolThreadCache#allocateSmall / allocateNormal 是第一道快速路径，命中线程缓存时无需触碰 Arena 的共享链表，坐标为 buffer/.../PoolThreadCache.java:143-168。

4.2 自适应路径

AdaptivePoolingAllocator.allocate
   │ size <= MAX_POOLED_BUF_SIZE
   ▼
size class -> MagazineGroup -> current Chunk
   │ miss / low memory / large buffer
   ▼
allocateFallback -> one-off chunk -> AdaptiveByteBuf

AdaptivePoolingAllocator#allocate 根据大小选择 size class 和线程本地 magazine；低内存或线程本地清理条件不满足时回退到共享 magazine，坐标为 buffer/src/main/java/io/netty/buffer/AdaptivePoolingAllocator.java:262-285。分配失败时会建立一次性 Chunk，坐标为 AdaptivePoolingAllocator.java:305-329。

这条路径的设计重点不是固定的 page/chunk 利用率链，而是根据分配大小、线程局部性和内存压力动态选择 magazine，并通过 ChunkController 计算初始容量，坐标为 AdaptivePoolingAllocator.java:1395-1414。

引用计数

allocate -> refCnt = 1
retain   -> refCnt + 1
release  -> refCnt - 1
refCnt=0 -> deallocate -> return pool memory

引用计数绕过 GC 的关键收益是：ByteBuf 归还时机与业务对象是否仍存活无关。代价是所有权必须明确：Pipeline 传递、异步保存、Composite 组合和异常路径都可能改变释放责任。

为什么不用全局对象池

全局池需要在每次分配时争用共享队列或锁，容易把 GC 问题转成竞争问题。线程本地缓存把绝大多数热路径限制在当前线程；只有缓存 miss、Chunk 链接和跨线程归还才触碰更重的协调逻辑。

参数与调优

参数/因素	影响	风险
direct buffer 偏好	减少 I/O 拷贝	堆外上限不足时 OOM
`maxCapacity`	控制扩容上限	过大可能保留过多池内存
线程本地缓存容量	提升命中率	长生命周期线程持有内存
leak detector	发现未释放引用	高级别检测有额外开销

边界与踩坑

ByteBuf 传入异步任务前需要 retain，任务结束后对应 release。
CompositeByteBuf#addComponent 会转移组件的 release 所有权，且默认不增加 writerIndex；源码注释和实现见 buffer/.../CompositeByteBuf.java:154-180、221-238。
内存池命中率高不代表堆外稳定；必须同时观察 allocator metric、JVM direct memory 和业务释放路径。
4.2 的自适应 allocator 不能用 4.1 的 pageSize、maxOrder 参数直接推导其全部行为。

可迁移知识

“线程本地快速路径 + 共享慢路径 + 显式所有权”适合对象池、连接池、消息缓冲和临时文件句柄。设计时必须同时定义缓存淘汰和异常释放，否则局部优化会制造长期泄漏。

面试锚点：Arena、Chunk、Subpage 分别解决什么问题？为什么 ByteBuf 必须引用计数？4.2 的 AdaptivePoolingAllocator 与经典池有什么不同？