直接使用 allocateDirect() 并不能自动提升 I/O 性能，关键在于配合零拷贝系统调用（如 transferTo、map）、避免 CPU 搬运、合理选型与大小、显式管理生命周期，并通过 strace 和监控验证链路是否真正打通。
直接用 allocateDirect() 并不能自动提升 I/O 性能，关键在于让数据路径真正绕过 JVM 堆、减少 CPU 搬运——这需要缓冲区类型、系统调用、内存管理三者协同。
必须配合零拷贝系统调用才有效
DirectByteBuffer 本身只是提供了堆外内存地址，真正减少拷贝要靠底层支持的传输方式：
-
文件到网络：用
FileChannel.transferTo()或SocketChannel.write()，内核可直接从页缓存搬数据到网卡 DMA 区域 -
文件映射场景：用
FileChannel.map()得到MappedByteBuffer，读写即操作内存页，避免 read/write 系统调用 -
避免手动搬数据：别在 DirectBuffer 上反复调
get()/put()，否则仍会触发 CPU 拷贝，反而比 HeapBuffer 更慢
按场景选对分配方式和大小
不是越大越好，也不是越直接越快，得看实际负载：
- 高频短连接（如 HTTP 请求）：用池化 DirectBuffer（如 Netty 的
PooledByteBufAllocator），避免每次allocateDirect()的 JNI 开销 - 大文件分发或流式传输：单次分配 8KB～64KB 较优，实测比 1KB 快 3～6 倍，再大收益趋缓
- 协议头固定长度（如 32 字节 magic + length）：精确分配
ByteBuffer.allocateDirect(32)，不浪费也不扩容
必须管住生命周期，否则很快 OOM
DirectBuffer 内存由 OS 分配，JVM 不负责立即释放，泄漏风险极高：
立即学习“Java免费学习笔记（深入）”；
- 显式限制上限：
-XX:MaxDirectMemorySize=512m，防止无节制增长 - Netty 用户务必调
.release()，尤其在ChannelHandler中完成读写后；未 release 的 PooledBuffer 会持续占位 - 原生
ByteBuffer虽有 Cleaner 异步回收，但若 GC 压力小或 Cleaner 队列阻塞，内存可能数分钟不释放
调试与验证是否真起作用
不能只看代码用了 DirectBuffer，要确认零拷贝链路打通：
- 用
strace -e trace=sendfile,splice,read,write观察是否出现sendfile()调用，而非大量read()+write() - 监控
java.nio.Bits.reservedMemory（通过 JMX）或NativeMemoryTracking，确认 Direct 内存使用平稳 - 对比开启
transferTo和纯buffer.get()/put()的 CPU 占用率，零拷贝下 sys 时间应明显下降
