DirectByteBuffer通过绕过JVM堆、由OS直接分配内存，配合SocketChannel.write()或transferTo()等native调用实现零拷贝，省去用户态到内核态的数据拷贝；其底层调用Unsafe.allocateMemory()并绑定Cleaner回收，需合理池化与监控以防泄漏。
Java NIO 通过直接内存（Direct Memory）绕过 JVM 堆，让 Socket I/O 操作跳过用户态到内核态的数据拷贝，从而显著降低数据传输开销。关键不在于“用了 DirectByteBuffer”，而在于配合支持零拷贝的通道操作（如 SocketChannel.write() 或 FileChannel.transferTo()），使操作系统能直接访问那块本地内存。
用 allocateDirect 分配真正的堆外缓冲区
调用 ByteBuffer.allocateDirect(size) 会触发底层 Unsafe.allocateMemory() 向操作系统申请内存，这块内存不受 GC 管理，JVM 只保留一个轻量级的 DirectByteBuffer 对象作为引用，并通过 Cleaner 在合适时机释放。与 allocate() 不同，它不经过堆，也就避免了后续 I/O 中「堆 → 本地缓冲区」的复制步骤。
- 适合中大块数据（如单次发送 ≥ 4KB），小 buffer 频繁分配反而增加 native 内存管理负担
- 注意监控直接内存使用：可通过 JVM 参数
-XX:MaxDirectMemorySize限制，否则可能触发OutOfMemoryError: Direct buffer memory
写入 Socket 时必须用 write(ByteBuffer) 且传入 DirectBuffer
SocketChannel.write(ByteBuffer) 方法在检测到参数是 DirectByteBuffer 时，会直接把其内部的内存地址传给 native 层的 writev 或 send 系统调用，OS 无需先拷贝数据到自己的临时缓冲区——这省掉了传统堆缓冲区场景下「JVM 堆 → kernel socket buffer」这一整轮 CPU 拷贝。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 不要把
DirectByteBuffer的内容先 get() 到 byte[]，再用write(ByteBuffer.wrap(...))，那样就退回堆内路径了 - 确保 buffer 处于可读状态（
flip()后 position ≤ limit），否则 write 可能写入 0 字节
大文件网络传输优先用 transferTo 实现真正零拷贝
如果目标是把磁盘文件发给客户端（比如静态资源服务），FileChannel.transferTo(position, count, WritableByteChannel) 是更优选择。它在 Linux 上直接映射为 sendfile() 系统调用，数据全程在内核空间流转：「磁盘 → page cache → socket buffer → 网卡」，完全不经过用户态内存，连 DirectBuffer 都不需要手动构造。
立即学习“Java免费学习笔记（深入）”；
- 要求源通道是
FileChannel，目标通道支持（如SocketChannel） - Windows 下对应
TransmitFile()，macOS 支持有限；小文件（ - 注意：transferTo 可能因底层限制一次未传完，需循环调用并更新 position
避免常见误区：不是所有 DirectBuffer 都能零拷贝
零拷贝效果依赖整个链路是否“贯通”。例如：
- 用
HeapByteBuffer调用write()：JVM 必须先复制到临时 DirectBuffer，多一次拷贝 - 用
DirectByteBuffer但目标是OutputStream（如socket.getOutputStream().write()）：走的是传统 BIO 路径，仍会拷贝进堆 - 没关闭 channel 或没清理 buffer 引用：DirectBuffer 占用的 native 内存不会被及时回收，容易泄漏
