Java NIO 使用堆外内存的核心原因是绕过JVM堆限制以实现高效可控I/O，避免GC干扰、支持零拷贝、分离生命周期，并需显式管控防OOM。
Java NIO 使用堆外内存（DirectMemory），核心原因是为了绕过 JVM 堆内存的限制，实现更高效、更可控的数据传输，尤其在高吞吐 I/O 场景下。
避免 GC 干扰数据通路
JVM 堆内存受垃圾回收机制管理：对象可能被移动、压缩，地址不固定；而网络或文件 I/O 操作需要稳定、连续、可被 DMA（直接内存访问）设备识别的内存区域。堆外内存由操作系统直接分配（如通过 malloc 或 mmap），物理地址固定、不可被 GC 移动，内核可直接读写——这使得 SocketChannel.write() 或 FileChannel.transferTo() 能跳过中间拷贝，真正发挥零拷贝能力。
若用堆内 ByteBuffer，JVM 必须先将数据从堆拷到内核缓冲区，多一次用户态内存拷贝；而 DirectByteBuffer 的地址可直接传给系统调用，省掉这步。
支持真正的零拷贝机制
Linux 的 sendfile()、Windows 的 TransmitFile() 等系统调用，要求源缓冲区是“内核可直接访问”的——只有堆外内存满足这一条件。例如：
- transferTo() + FileChannel → SocketChannel：数据从磁盘页缓存直接送入网卡协议栈，全程不经过用户态内存
- 若传入的是 HeapByteBuffer，JVM 会自动退化为普通 read/write 模式，失去零拷贝意义
- 注意：该优化仅对 FileChannel 作源、且目标为 socket 类型 channel 时生效
分离数据生命周期与 GC 周期
堆内内存的分配/释放快，但频繁 GC（尤其大对象晋升到老年代）会导致 STW 和延迟抖动。堆外内存虽分配成本高（涉及 JNI 和系统调用），但它：
- 不参与堆内存的分代管理，不会触发 Young GC 或 CMS/FGC
- 其生命周期绑定于 DirectByteBuffer 对象：对象被 GC 后，由 Cleaner 异步释放对应内存
- 适合长期持有、复用的缓冲区（如 Netty 的 PooledByteBuf）
需主动管控，否则易引发 OOM
堆外内存不受 -Xmx 控制，必须显式设置 -XX:MaxDirectMemorySize。否则：
- 即使堆内存充足，DirectByteBuffer 持续分配仍会耗尽物理内存
- OOM 错误提示为：java.lang.OutOfMemoryError: Direct buffer memory
- Cleaner 回收有延迟，且依赖 GC 触发；大量 DirectByteBuffer 进入老年代却不触发 Full GC，会导致内存“滞涨”
