isDirect 返回 true 仅表示 ByteBuffer 使用堆外内存，不保证绕过内核拷贝；能否零拷贝取决于具体 NIO API（如 transferTo）及底层系统调用（如 sendfile）是否实际启用。
isDirect 返回 true 就代表能绕过内核拷贝？
不是。isDirect 只是告诉你这个 ByteBuffer 的 backing memory 是否在堆外（即是否为 DirectByteBuffer），它本身不参与、也不保证任何 I/O 路径优化。能否绕过内核态拷贝，取决于后续使用的具体 NIO API 和底层系统调用，比如 FileChannel.transferTo 或 SocketChannel.write 是否实际触发了零拷贝路径（如 Linux 的 sendfile 或 splice）。
常见误解是：只要 buffer.isDirect() 为 true，read/write 就一定快。但如果你用 channel.read(buffer) 读到一个 DirectByteBuffer，而底层驱动或 JVM 实现没走 direct path（例如某些虚拟化环境或旧版 JDK），它仍可能先拷贝进内核缓冲区再中转——此时 isDirect 仅反映内存位置，不等于性能提升。
为什么只有 DirectByteBuffer 才可能触发零拷贝 I/O
根本原因在于内存可见性与访问权限：
- 内核态无法直接访问 JVM 堆内存（
HeapByteBuffer底层是byte[]），必须由用户态把数据 copy 进内核缓冲区，这是强制的两次拷贝（user → kernel → device） -
DirectByteBuffer的数据存放在操作系统直接管理的堆外内存，JVM 通过Unsafe.allocateMemory向 OS 申请，这块地址对内核是“可见且可映射”的，所以像sendfile这类系统调用可以直接以该地址为源，让 DMA 控制器直取数据 - 注意：即使用了
DirectByteBuffer，若调用的是buffer.get()/put()等操作，仍是纯用户态内存访问，和内核无关；只有配合支持 direct path 的 channel 方法时，才可能跳过中间拷贝
isDirect 判断失效的典型场景
以下情况会让 isDirect 的返回值“看似正确”，但实际失去零拷贝意义：
- 使用
ByteBuffer.wrap(byte[])包装数组后调用asReadOnlyBuffer()或duplicate()，得到的仍是HeapByteBuffer，isDirect()恒为false，哪怕你之后调用allocateDirect创建新 buffer 也无济于事 - 某些 Netty 或自定义 Buffer 封装类重写了
isDirect()，返回值被 mock 成true，但底层仍是堆内数组（常见于测试 stub） - JDK 版本低于 9 且未启用
-XX:+UseG1GC时，DirectByteBuffer的Cleaner回收可能延迟，导致大量isDirect() == true的 buffer 占着内存却不再参与 I/O，你以为它在加速，其实只是泄漏前的假象
验证是否真走零拷贝的实操建议
别只信 isDirect，要结合运行时行为确认：
- 用
strace -e trace=sendfile,splice,writev,readv观察 Java 进程是否发出这些系统调用（而非普通read/write） - 检查 JVM 参数是否设了
-XX:MaxDirectMemorySize，并监控java.nio.Bits.reservedMemory统计值是否随 I/O 增长——不增长说明 buffer 没被真正用于 direct I/O - 在关键 write 调用前后打点：
System.nanoTime()+buffer.address()（需反射获取，仅调试用），确认同一块地址是否被反复复用；如果每次 write 都 new 一个DirectByteBuffer，那 GC 压力和分配开销反而会抵消零拷贝收益
最易被忽略的一点：isDirect 是静态属性，但它背后那块堆外内存的生命周期完全独立于 buffer 对象——buffer 被 GC 后，内存未必立刻释放；而只要内存还挂着，它就可能被误复用或干扰其他 direct 操作。判断是否“真正绕过内核”，从来不只是看一个布尔值。
