Java NIO底层原理核心在于Buffer内存控制、Channel系统调用映射、Selector事件多路复用三主线：Buffer通过capacity/position/limit指针由Unsafe或数组索引直接操控，分堆内（GC管理）与堆外（零拷贝但需Cleaner释放）；Channel封装系统调用，如FileChannel用pread/pwrite和sendfile，SocketChannel依赖O_NONBLOCK实现非阻塞；Selector在Linux基于epoll、macOS用kqueue、Windows模拟epoll语义，通过SelectionKey桥接Java对象与内核fd及事件掩码。
Buffer 的底层内存与状态流转
Buffer 的核心是三个指针：capacity（总容量）、position（当前读写位置）、limit（有效数据边界）。它们不是简单变量，而是由 JVM 通过 Unsafe 或堆内数组索引直接操控。
- 堆内 Buffer（allocate）：底层是 byte[] 数组，所有操作最终转为数组下标访问，受 GC 管理
-
堆外 Buffer（allocateDirect）：调用
Unsafe.allocateMemory向操作系统申请内存，绕过 JVM 堆，避免拷贝；但需依赖 Cleaner 机制在 GC 时释放，否则易内存泄漏 - flip()/clear()/rewind() 等方法本质是重置 position/limit/mark 的数值，不涉及数据搬运，极轻量
Channel 如何对接操作系统
Channel 是 Java 层抽象，真正干活的是它背后封装的系统调用。不同 Channel 类型对应不同内核接口：
-
FileChannel：Linux 下走
pread/pwrite（支持随机读写），零拷贝用transferTo/transferFrom触发sendfile或splice系统调用 -
SocketChannel / ServerSocketChannel：基于非阻塞 socket，调用
connect()、read()、write()时，若无数据或连接未就绪，立即返回 -1 或抛出IOException（如NotYetConnectedException），而非挂起线程 -
所有网络 Channel都依赖
configureBlocking(false)设置底层 socket 的O_NONBLOCK标志，这是非阻塞行为的起点
Selector 的跨平台事件驱动实现
Selector 是 NIO 并发能力的核心，它的“单线程管多连接”不是 Java 自己轮询实现的，而是委托给操作系统原生多路复用器：
- Linux → epoll：通过
epoll_create、epoll_ctl（注册/修改事件）、epoll_wait（阻塞等待就绪事件）完成 - macOS/BSD → kqueue
- Windows → IOCP（注意：JDK 中 Selector 在 Windows 上实际仍模拟 epoll 语义，并未完全使用 IOCP）
- 注册 Channel 时生成
SelectionKey，它内部持有一个 native 的文件描述符（fd）和事件掩码（OP_READ 等），是 Java 对象与内核事件结构体之间的桥梁
调试与验证的关键切入点
想确认底层行为是否符合预期，可结合以下方式交叉验证：
立即学习“Java免费学习笔记（深入）”；
- 用
strace -e trace=epoll_wait,epoll_ctl,read,write,sendfile运行 NIO 程序，观察真实系统调用 - 开启 JVM 参数
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider（显式指定 Linux 实现） - 用 JFR（Java Flight Recorder）录制 I/O 事件，查看
jdk.SocketRead、jdk.SocketWrite等事件耗时与频率 - 对比
ByteBuffer.allocate(1024)和allocateDirect(1024)在大文件传输中的 GC 日志与吞吐差异
