jvm本身不直接实现epoll或select，而是依赖linux内核的i/o多路复用能力；java nio selector在linux 2.6+上默认通过epoll（由epollselectorimpl实现）驱动，突破1024文件描述符限制，支持数十万并发连接，并具备o(1)就绪通知、低拷贝开销及边缘触发（et）模式等优势。
JVM本身不直接实现 epoll 或 select，它依赖底层操作系统提供的 I/O 多路复用能力。真正起决定性作用的是 JVM 所运行的 Linux 内核，以及上层 Java 网络框架（如 Netty、Tomcat NIO connector）如何封装和调用这些系统调用。所谓“JVM 中的 Epoll 模型”，实际是指 Java NIO 的 Selector 在 Linux 上的底层实现——当使用 Selector.open() 且系统为 Linux 2.6+ 时，OpenJDK 默认会通过 epoll（而非 select/poll）来驱动；这是由 sun.nio.ch.EPollSelectorImpl 完成的。
连接规模无硬上限，彻底摆脱 1024 束缚
select 使用固定大小的位图（fd_set），默认最多监听 1024 个 fd（FD_SETSIZE），超出需改宏重编译内核，极不现实。JVM 的 NIO Selector 若走 select 实现（如在非 Linux 系统或降级场景），同样受此限制。而 epoll 基于红黑树管理 fd，上限等于系统允许打开的最大文件数（/proc/sys/fs/file-max），通常数十万起步。这意味着单个 Java 进程轻松支撑 10 万+ 并发连接，无需分进程/分端口等复杂架构妥协。
就绪通知零遍历，时间复杂度从 O(n) 降至 O(1)
select 每次调用都要把整个 fd 集合从用户态拷贝进内核，并由内核线性扫描全部 fd 判断状态；poll 类似，只是改用链表存储，仍需全量轮询。当连接数达数万，而活跃连接仅数百时，这种“扫全表”开销巨大。epoll 则不同：注册一次后，内核通过中断回调将就绪 fd 直接挂入就绪链表；epoll_wait() 只返回已就绪的 fd 列表，Java NIO Selector 的 select() 方法底层即调用它——应用线程完全跳过无效遍历，CPU 时间真正花在业务处理上。
减少内存拷贝与上下文切换压力
select/poll 每次调用都需在用户态与内核态之间整批复制 fd 集合（结构体数组或位图），数据量随连接数线性增长。epoll 采用“一次注册、事件驱动”设计：epoll_ctl() 注册 fd 后，内核长期持有其引用；epoll_wait() 仅需传递一个存放就绪事件的小缓冲区（如 epoll_event[]），多数情况下几十字节即可。这对 GC 压力、堆外内存管理及系统调用延迟均有显著优化，尤其在高吞吐低延迟场景下更明显。
支持边缘触发（ET）模式，减少重复通知
select 和 poll 均为水平触发（LT）：只要 fd 处于就绪态（如 socket 接收缓冲区非空），每次 select() 都会报告。若应用未一次性读完数据，下次调用仍会返回该 fd，造成“惊群”和冗余唤醒。epoll 支持 ET 模式（需设置 EPOLLET），仅在状态**变化瞬间**通知一次（例如从不可读变为可读）。这要求应用使用非阻塞 I/O 并循环读取直到 EAGAIN，但换来的是更少的系统调用次数和更可控的事件流——Netty 等高性能框架默认启用 ET，正是为了压榨单线程 Reactor 的吞吐极限。
