DirectByteBuffer通过绕过JVM堆实现零拷贝优化，使数据在内核与硬件间直传，减少CPU参与的冗余拷贝；适配transferTo等系统调用，降低GC压力与内存带宽占用，但需注意分配成本高、调试难及生命周期管理。
直接内存（DirectByteBuffer）在零拷贝场景中能绕过 JVM 堆，让数据在内核空间与硬件设备之间直接流转，省掉一次 CPU 参与的用户态拷贝。核心优势不是“完全不拷贝”，而是减少冗余的、由 CPU 主导的跨空间复制。
避免用户态与内核态之间的额外数据搬运
传统堆内存 ByteBuffer（HeapByteBuffer）读写文件或网络时，数据必须从内核缓冲区（如 page cache 或 socket buffer）先拷贝到 JVM 堆里，应用处理完再拷回内核——这中间至少两次 CPU 拷贝。而 DirectByteBuffer 的内存地址可被操作系统直接访问，JVM 通过 JNI 调用 native 方法（如 sendfile、transferTo）时，内核能直接操作这块内存，无需把数据拉进用户空间。
- HeapByteBuffer：数据路径为「磁盘 → 内核页缓存 → JVM 堆 → 内核 socket 缓冲区 → 网卡」
- DirectByteBuffer：可简化为「磁盘 → 内核页缓存 → DirectBuffer 内存 → 网卡」（借助 transferTo + 支持零拷贝的底层系统调用）
适配操作系统级零拷贝机制
Java 中真正实现零拷贝的关键 API 是 FileChannel.transferTo() 和 SocketChannel.write() 配合 DirectBuffer。这些方法在 Linux 下会尝试调用 sendfile() 或 splice() 系统调用——它们要求源/目标缓冲区位于内核可直接寻址的内存区域。HeapByteBuffer 不满足这个前提，系统只能退化为普通 read/write 流程；DirectByteBuffer 则天然契合。
- transferTo(source, position, count, targetChannel) 在 targetChannel 是 SocketChannel 且 source 是 FileChannel 时，若底层支持，就会跳过用户空间
- 若 targetChannel 对应的 buffer 是 HeapByteBuffer，JVM 必须分配临时 DirectBuffer 中转，反而增加开销
降低 GC 压力与内存带宽占用
大流量 I/O 场景下频繁分配回收堆内 byte[] 容易触发 Young GC，甚至晋升到老年代造成 STW。DirectByteBuffer 的内存不在堆上，不受 GC 管理（只受 Cleaner 异步回收），减少了 Stop-The-World 风险。同时，DMA 控制器可直接在堆外内存和网卡/NVMe 设备间传输数据，节省了内存总线带宽。
- 堆外内存大小受 -XX:MaxDirectMemorySize 限制，默认通常等于 -Xmx
- 未及时释放的 DirectBuffer 会导致 OOM: Direct buffer memory，需注意资源生命周期管理
使用时的关键注意事项
DirectByteBuffer 并非万能加速器，用错反而拖慢性能。它适合长生命周期、高吞吐、以 I/O 为主的缓冲区（如网络连接的接收/发送缓冲区），不适合短时小对象或频繁修改的场景。
- 分配成本比堆内存高，因为要走系统 mmap/malloc，不适合高频创建销毁
- 不能被 JVM JIT 优化（如逃逸分析、栈上分配），访问局部性略差
- 调试困难：堆外内存无法用 jmap/jstat 直接观察，需借助 Native Memory Tracking（NMT）
