高性能网络编程中的 ByteBuffer 分配与回收策略

—— 基于 t-io 的实践优化

背景

在 Java NIO 网络编程中，ByteBuffer 是最基础的 I/O 缓冲容器。默认情况下，很多框架会在发送响应时直接调用：

ByteBuffer buf = ByteBuffer.allocate(...)      // 堆内存
// 或
ByteBuffer buf = ByteBuffer.allocateDirect(...) // 堆外内存

这种“临时分配 → 写出 → 交由 GC 回收”的模式，在高并发场景下会遇到几个问题：

为了解决这些问题，我们在 t-io 的 HTTP 响应链路上，对 ByteBuffer 的分配和回收进行了重构。

不再直接分配
- HttpResponseEncoder 中原先 ByteBuffer.allocate(...) / allocateDirect(...) 的地方，统一改成 从池借用：
```
ByteBuffer buf = Buffers.DIRECT_POOL.borrow(size);
```
- 文件传输（非 SSL）仍使用 FileChannel.transferTo 零拷贝，不需要额外 buffer。
自动回收
- 在 SendPacketTask.sendByteBuffer() 里，如果发现发送的 buffer 是 direct，就给它挂上一个 returnToPool 回调：
```
Runnable returnToPool = () -> Buffers.DIRECT_POOL.giveBack(buf);
WriteCompletionVo vo = new WriteCompletionVo(buf, packet, false, returnToPool);
```
- WriteCompletionHandler.completed() 在写完并调用 handle(...) 后，会自动执行这个回调，把 buffer 归还池。
池化策略
- 池内部按照 2 的幂次分桶：1KB、2KB、4KB … 1MB。
- 每个线程有自己的本地缓存（避免锁竞争）；全局还有一个共享队列作为兜底。
- 超过 maxBucketSize 的大 buffer（例如 >1MB 的响应体），直接 allocateDirect，写完交给 Cleaner 回收，不入池。

HttpResponseEncoder 根据 header+body 计算所需容量，从池借一个 direct buffer。
写入响应行、header、body → 返回给 SendPacketTask。
SendPacketTask 调用 sendByteBuffer(...)，挂上归还回调。
WriteCompletionHandler.completed() 检测到写完，执行 returnToPool.run() → buffer 清空并放回池。

非 SSL：
- Header 部分依然用池借 buffer，写完归还池。
- 文件体通过 FileChannel.transferTo() 零拷贝直接进网卡 → 没有额外分配。
SSL：
- 无法用零拷贝，只能分块读文件。
- 每次循环从池借一个 64KB direct buffer → 读文件 → SSL 加密 → 写出 → 归还池。

不同响应大小差异大（JSON 小报文、静态文件 header、中等二进制数据）。
分桶能保证复用时减少内存浪费：
- 请求 2KB 时，借一个 2KB 桶；
- 请求 40KB 时，借一个 64KB 桶；
- 避免全都用 1MB 桶导致浪费。

通过在 t-io 的发送链路上引入 Direct ByteBuffer 池化，我们实现了：

配合 零拷贝传输 和 SSL 分块池化，形成了一整套高效的 ByteBuffer 分配与回收策略。

这套机制的核心优势是：

非常适合高并发场景下的 HTTP/WebSocket/自定义协议服务。