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免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
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 注销——这不是底层问题，是你代码里的性能悬崖。
