java nio底层自动选用最优多路复用机制：linux默认epoll（jdk7+），macos/freebsd用kqueue，windows用select；性能差异源于实现原理，合理编码比机制选择更关键。
Java 的 NIO（New I/O）底层依赖操作系统提供的多路复用机制，但 Java 本身不直接暴露 select、poll 或 epoll 系统调用——它通过 JNI 封装在 Selector 实现中。不同平台和 JDK 版本会自动选用最合适的内核机制，开发者无法手动切换。因此，“对比它们对 Java 多路复用的影响”，本质是理解底层差异如何间接影响 Java 应用的行为表现。
Linux 上 Java 默认用 epoll（JDK 7+）
从 JDK 7 开始，Linux 平台的 Selector.open() 默认使用 epoll（具体为 epoll_wait），前提是内核支持（2.6+）。这意味着：
- 单个 Selector 可高效管理数万并发连接，时间复杂度接近 O(1)（就绪事件通知）
- 不会重复遍历全部注册的 Channel（不像 select/poll 每次都扫描整个 fd 集合）
- 边缘触发（ET）模式未被 Java NIO 公开使用，Java 仍基于水平触发（LT）语义封装
select 和 poll 在 Java 中基本不启用（除非降级或特殊配置）
Java 不提供 API 强制使用 select 或 poll。但在以下情况可能退回到较旧实现：
- JDK 6 或更早版本运行在 Linux 上（默认用 poll）
- 启动时添加 JVM 参数
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider（强制 poll） - 在非 Linux 系统（如 macOS / FreeBSD）上，Java 使用 kqueue；Windows 上使用 select（因无原生 epoll/kqueue 支持）
这些场景下性能差异明显：select/poll 的轮询开销随连接数线性增长，高并发时 CPU 升高、延迟上升，尤其当空闲连接远多于活跃连接时。
真正影响 Java 性能的关键不是“选哪个”，而是用法是否合理
即使底层是 epoll，错误的编码习惯也会抹平优势：
- 每次
select()调用后未及时处理所有就绪 Channel，导致下次 select 返回相同就绪事件（饥饿或重复唤醒） - 在 selector 线程中执行阻塞操作（如文件读写、数据库调用），阻塞整个事件循环
- 注册了大量 Channel 却长期不活跃，epoll 虽高效，但内核仍需维护 eventfd 和红黑树节点，内存与上下文切换成本不可忽略
- 未设置合理的
SO_TIMEOUT或未正确处理 OP_CONNECT/OP_WRITE 的状态流转，引发连接假死或写事件泛滥
可通过 JVM 参数和工具验证实际使用的机制
确认当前运行时的 Selector 类型：
- 启动时加参数：
-Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true -XX:+PrintGCDetails无直接打印，但可配合调试或 JFR - 使用
jstack查看 NIO 线程栈：若看到EPollArrayWrapper.epollWait，说明在用 epoll；若为PollArrayWrapper.poll，则是 poll - JDK 19+ 支持 JFR 事件
jdk.SocketRead/jdk.SocketWrite，结合系统调用追踪（如perf trace -e syscalls:sys_enter_epoll_wait,sys_enter_select）可交叉验证
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
