DirectByteBuffer提升I/O速度的核心在于减少用户态与内核态间的数据拷贝，需配合transferTo、sendfile等系统调用才能实现真正零拷贝；单纯替换缓冲区类型无效，且存在分配慢、回收不可控、无自动扩容等代价。
用 DirectByteBuffer 提升 I/O 速度，核心不是“绕开堆内存”本身，而是减少数据在用户态和内核态之间不必要的拷贝。它真正起效的前提是配合底层系统调用（如 transferTo、sendfile），而不是单纯换一个缓冲区类型。
为什么 DirectByteBuffer 能减少拷贝
传统堆内存（HeapByteBuffer）读文件时的路径是：
- 磁盘 → 内核页缓存（Page Cache）
- 内核页缓存 → JVM 堆内存（CPU 搬运一次）
- JVM 堆内存 → 内核 Socket 缓冲区（CPU 再搬运一次）→ 网卡
而 DirectByteBuffer 的内存由操作系统直接分配，JVM 只提供一个地址引用。数据流动变成：
- 磁盘 → 内核页缓存
- 内核页缓存 ↔ 直接内存（零拷贝路径可打通）
- 直接内存 → 网卡（通过
FileChannel.transferTo()或SocketChannel.write()触发 DMA 或 sendfile）
关键点：只有当通道操作能跳过 CPU 搬运，才真正实现“零拷贝”。否则只是少了一次堆内复制，仍需 CPU 参与。
立即学习“Java免费学习笔记（深入）”；
怎么正确创建和使用 DirectByteBuffer
不能只靠 allocateDirect() 就完事，得匹配 I/O 场景：
- 用
ByteBuffer.allocateDirect(1024 * 1024)分配固定大小缓冲区，避免频繁分配（分配比堆慢 3–8 倍） - 写入后必须调用
flip()，读取完记得clear()或compact()复用 - 优先交给
FileChannel.read(buffer)或SocketChannel.write(buffer)，别自己get()/put()搬数据 - 大文件传输尽量用
channel.transferTo(position, count, targetChannel)，它不依赖 buffer 内容，直接走内核零拷贝路径
必须注意的性能代价
DirectByteBuffer 不是“更快的 ByteBuffer”，它是权衡选择：
- 分配慢：每次
allocateDirect()都要 JNI 调用malloc，不适合高频小对象场景 - 回收不可控：依赖 GC 触发
Cleaner异步释放，若堆压力小，内存可能长期不释放，引发OutOfMemoryError: Direct buffer memory - 无自动扩容：大小固定，不能像堆数组那样 grow，需要自己管理或引入池化（如 Netty 的
PooledByteBufAllocator） - 调试困难：堆外内存无法被常规堆 dump 工具捕获，需用
-XX:NativeMemoryTracking=detail+jcmd VM.native_memory追踪
什么情况下值得用
不是所有 I/O 都适合。适用场景有明确特征：
- 高吞吐网络服务（如 RPC 网关、消息代理），单连接持续收发大量数据
- 大文件顺序读写（视频转码、日志归档），且能配合
transferTo/transferFrom - 对 GC 停顿敏感（如金融交易系统），需规避大 buffer 占用新生代
- 已有成熟池化机制（如 Netty、Dubbo），避免裸用
allocateDirect
小数据包、短连接、低频 I/O，用堆内存更省事也更高效。
