java selector在linux上默认用epoll，前提是jdk 7+、内核2.6+且未强制降级；epoll基于红黑树和就绪链表实现o(1)增删与通知，而select/poll需o(n)遍历全量fd集合。
Java Selector 底层到底是 epoll 还是 select？
Java Selector 在 Linux 上默认用的是 epoll，不是 select 或 poll。但这个“默认”有前提：JDK 7+、Linux 内核 2.6+、且未显式禁用（比如通过 -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider 强制切到 poll）。epoll 是真正支撑 Java NIO 单线程万级并发的底层基础。
关键点在于：Selector.open() 返回的具体实现类，取决于 SelectorProvider 的加载顺序和系统能力探测结果。JVM 启动时会尝试加载 EPollSelectorProvider，失败才回退到 PollSelectorProvider。
-
epoll使用红黑树 + 就绪链表，时间复杂度 O(1) 增删监听、O(1) 获取就绪事件 -
poll和select都需每次传入全量 fd 集合，遍历扫描，O(n) 复杂度，n 是注册通道总数 - 当你的
Selector注册了 5000 个SocketChannel，select()调用每次都要拷贝并扫描 5000 个 fd；而epoll_wait()只返回真正就绪的那几个
为什么 selector.select() 在高负载下仍可能变慢？
即使底层是 epoll，selector.select() 的耗时也不恒定为常数。它受三个非内核因素影响：
- 用户态
selectedKeys()集合的清理开销：如果没及时调用iterator.remove()，集合会持续膨胀，下次select()返回后遍历成本升高 - 大量无效 SelectionKey 残留：比如连接异常断开后未取消注册，
key.cancel()没调或没在下一次select()前触发清理，这些 key 仍占位、参与内部状态维护 - JVM GC 压力传导：频繁创建临时
ByteBuffer或处理大消息导致 Young GC 频繁，间接拖慢事件循环线程——你看到select()“卡住”，实际是线程被 GC STW 暂停了
典型现象：select() 平均耗时 0.1ms，某次突然跳到 15ms，jstack 显示线程状态是 VM Thread，基本就是 GC 导致。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
selectNow() 真的完全不触发系统调用吗？
不是。selectNow() 依然会调用 epoll_wait(epollFd, events, maxEvents, 0)，只是把超时参数设为 0。它不阻塞，但仍有上下文切换和内核态检查开销。
更关键的是：selectNow() 不会自动清理已处理的 SelectionKey，也不会触发 cancelledKeys() 的批量注销。如果你在轮询中只用 selectNow() 而忽略 selector.keys().size() 持续增长，内存泄漏会比 select() 更隐蔽。
- 每调用一次
selectNow()，JVM 都要检查所有已注册 channel 的就绪状态，这部分逻辑仍在用户态完成 - 若你每毫秒调用一次
selectNow()，而实际只有 1% 时间有事件，相当于 99% 的调用纯属空转消耗 CPU - 对比
select(10)：最多等 10ms，有事件立刻返回，无事件也只花一次系统调用+等待，更省电、更利于调度器
跨平台时 Selector 性能边界怎么预估？
Linux（epoll）≈ macOS（kqueue）≈ Windows（IOCP），但三者对“就绪”的定义和触发时机有细微差异，直接影响你代码的健壮性：
- Linux
epoll对OP_WRITE的就绪判断较激进：只要 socket 发送缓冲区有空间就报告可写，容易造成忙等；Windows IOCP 则更保守，通常只在真正能发数据时才通知 - macOS
kqueue不支持OP_CONNECT的边缘触发模式，客户端 connect 后必须手动调用finishConnect()，否则 key 会一直就绪 - 所有平台都要求：channel 必须是非阻塞模式，否则注册会抛
IllegalBlockingModeException
真正容易被忽略的点：性能测试不能只看吞吐，还要看 selector.selectedKeys().size() 和 selector.keys().size() 的比值。长期运行后如果前者稳定在 10~20，后者却涨到 5000+，说明你的事件处理逻辑漏掉了 key 清理或 channel 注销——这不是底层问题，是你代码里的性能悬崖。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
