Java NIO在Linux底层通过epoll实现高效多路复用，核心是Selector.open()调用epoll_create1()创建独立epoll实例，注册Channel时用epoll_ctl插入红黑树，select()触发epoll_wait仅返回就绪fd，避免线性扫描。
Java NIO 的多路复用在 Linux 底层是通过 epoll 机制实现高效运行的，核心在于 JVM 将 Selector 的事件轮询委托给内核的 epoll 实例，避免了传统轮询（如 poll/select）的低效遍历和重复拷贝。
Java NIO 的 Selector 与 epoll 的映射关系
JVM 在 Linux 平台上（OpenJDK 默认）会为 Selector.open() 创建一个底层 epoll 实例：
- 调用
epoll_create1(0)创建 epoll 文件描述符（epfd），作为事件管理器； - 每个注册到
Selector的Channel（如SocketChannel）对应一个文件描述符（fd），JVM 内部调用epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event)将其加入红黑树； -
Selector.select()或select(timeout)最终触发epoll_wait(epfd, events, maxevents, timeout)，只返回已就绪的fd列表，而非全量扫描。
epoll 高效的关键设计被 JVM 充分利用
-
红黑树管理监听项：JVM 把每个注册的 Channel 映射为一个
epitem，插入内核红黑树。增删改事件（OP_READ/OP_WRITE）平均时间复杂度为 $O(\log N)$，远优于poll的 $O(N)$ 线性查找； -
就绪队列（Ready List）零拷贝通知：当 socket 收到数据、连接建立或写缓冲区就绪时，内核直接将对应
epitem插入就绪链表；epoll_wait仅从该链表复制就绪事件到用户空间，避免遍历全部监听项； -
边缘触发（ET）与水平触发（LT）支持：JVM 默认使用 LT 模式（兼容性好），但可通过
SelectionKey.interestOps()结合channel.configureBlocking(false)配合 ET 模式减少重复通知，提升吞吐。
实际运行中的关键表现
- 单个
Selector可稳定支撑数万并发连接，因为内核不随连接数线性增长开销； -
Selector.selectNow()对应非阻塞epoll_wait(..., 0)，适合事件驱动循环； -
Selector.wakeup()底层调用eventfd_write或管道写入，唤醒阻塞中的epoll_wait，保证外部事件可及时插入处理流程。
注意事项
-
Selector不是线程安全的：同一Selector实例不应被多个线程并发调用select()或close()； - 注册
Channel前必须设置为非阻塞模式（configureBlocking(false)），否则epoll_ctl会失败； -
SelectionKey.cancel()触发epoll_ctl(..., EPOLL_CTL_DEL, ...)，但需在下一次select()中才真正从红黑树移除——因此 cancel 后仍可能收到旧事件，建议检查key.isValid()。
本质上，Java NIO 并未重新发明轮询逻辑，而是把事件分发这一重活完全交给了 Linux 内核的 epoll，自己专注做用户态的事件分发、回调调度与 Buffer 管理。这种“内核做判断，用户做处理”的分工，正是它能支撑高并发低延迟服务的根本原因。
