java nio的selector在linux（jdk7+）默认用epoll，windows只能用select；epoll基于红黑树和就绪队列实现o(1)通知，select需o(n)线性扫描且受fd数量硬限制（通常1024），高并发下linux性能显著优于windows。
Java NIO 的 Selector 在不同操作系统上表现一致，但底层实现和实际行为有本质差异：Linux（JDK 7+）默认用 epoll，Windows 只能用 select。这种差异不改变 Java 编程接口，却直接影响高并发场景下的吞吐、延迟与资源消耗。
底层机制完全不同
Linux 上的 Selector 通过 EPollSelectorProvider 调用 epoll_wait()，内核用红黑树维护监听 FD，只通知真正就绪的通道，时间复杂度接近 O(1)；Windows 上则依赖 WindowsSelectorProvider，底层是 select() 系统调用，每次都要线性扫描全部注册的 socket，且受 FD 数量硬限制（默认 64 或 1024，取决于 JVM 启动配置和 Windows 版本）。
- epoll 支持数万连接无性能陡降，尤其空闲连接多时优势明显
- select 在连接数超过几百后，CPU 花费在轮询上的比例显著上升
- epoll 使用事件就绪队列 + mmap 共享内存，减少内核/用户空间拷贝；select 每次调用都需完整复制 fd_set 结构
API 行为表面一致，实际语义有隐含区别
Selector.select() 在两边都是阻塞调用，但“阻塞多久”和“为什么返回”逻辑不同：
- Linux epoll 返回通常意味着至少一个 Channel 就绪，或超时/中断；极少出现“假唤醒”
- Windows select 可能因系统内部信号、socket 关闭异常、甚至 TCP keepalive 包触发返回，导致空轮询概率更高
- epoll 支持边缘触发（ET），但 Java NIO 封装层始终以水平触发（LT）语义暴露，开发者无需也无法切换；Windows select 本身只有 LT 模式，这点反而统一
连接规模与稳定性表现分化明显
当并发连接稳定在数千级别时，两者都能工作；但一旦达到 10,000+ 连接，差异就会暴露：
- Linux：单个 Selector 可轻松支撑 5–10 万活跃连接，CPU 占用平稳，GC 压力小
- Windows：接近 1024 连接时，select 调用耗时开始明显增长；超过 3000 连接后，容易出现 select 返回后遍历
selectedKeys()时发现大量无效 key，或因 FD 耗尽导致Channel.open()失败 - Windows 下 socket 生命周期管理更敏感，close() 不及时易导致 FD 泄漏，而 epoll 对重复 close 更宽容
开发与调优策略应因地制宜
不能靠换平台解决设计问题，但需针对性规避短板：
- Windows 环境避免单 Selector 承载过多连接，可考虑按业务分组使用多个 Selector（如管理连接 vs 处理数据）
- Linux 下不必刻意拆分 Selector，但要注意
selectedKeys()必须及时清理，否则影响下一轮就绪判断 - 跨平台项目不要依赖
Selector.provider()类型做逻辑分支——Java 不保证运行时可切换，也不建议强行指定 Provider - 监控指标应区分：Linux 关注 epoll_wait 调用耗时与就绪数方差；Windows 则要盯住 select 调用平均耗时及无效 key 比例
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
