HeapByteBuffer适用于短时中转场景（如HTTP请求头解析、小段日志拼接），分配快、GC自动回收；DirectByteBuffer适用于高频I/O或零拷贝场景（如socket sendfile、大文件传输），需池化复用并手动管理内存，避免OOM。
选对分配方式，关键看数据生命周期、访问频率和是否涉及零拷贝。堆内还是堆外，不是性能越高越好，而是匹配场景才最稳。
短时中转用 heapBuffer
比如解析 HTTP 请求头、临时拼接小段日志、协议字段校验等——数据只用一两次，很快丢弃。这类场景直接用 ByteBuffer.allocate()（即 HeapByteBuffer）最合适：
- 分配快，JVM 堆内申请几乎无开销
- GC 自动回收，不用手动管理 .release()
- 避免 DirectBuffer 的 Cleaner 延迟回收风险
高频网络 I/O 优先选池化 DirectBuffer
Netty 或自研 NIO 服务中，I/O 线程持续收发包，每个连接每秒可能产生几十到上百次 buffer 分配/释放。此时应使用 PooledByteBufAllocator(true).buffer()（Netty）或自建 DirectBuffer 池：
- 复用已分配的堆外内存，避开反复 mmap/munmap 系统调用
- 避免 GC 扫描堆外引用，降低 STW 风险
- 需配合 -XX:MaxDirectMemorySize 限制总量，防 OOM
大块数据或需零拷贝时必须用 DirectBuffer
文件传输（transferTo）、socket sendfile、GPU 数据交换等场景，内核需要绕过 JVM 堆直接读写内存。这时只能用 allocateDirect() 或其池化变体：
立即学习“Java免费学习笔记（深入）”；
- HeapByteBuffer 无法参与零拷贝，数据必须先拷入堆外再进内核
- 单次分配大 buffer（如 1MB 文件切片）可考虑 Unpooled.directBuffer(size)，但务必在业务逻辑结束时调用 .release()
- 不及时 release 容易触发 Direct buffer memory OOM
固定结构数据按需精算容量
协议头 32 字节、魔数+版本号共 8 字节、JSON 长度前缀 4 字节……这些已知大小的数据，别盲目用 1KB 起步：
- ByteBuffer.allocate(32) 比 allocate(1024) 更省内存、更少 GC 压力
- 变长消息建议用 CompositeByteBuf 拼接多个小 buffer，避免频繁扩容复制
- 不要依赖自动扩容：ByteBuffer 不支持 resize，扩容需手动 new + copy
