java nio的selector默认且仅使用水平触发（lt）语义，底层虽依赖epoll或kqueue，但jvm未暴露et开关，也不保证et一致性；其行为是逻辑lt：就绪事件持续通知直至状态改变。
Java NIO 的 Selector 本身不直接暴露边缘触发（ET）或水平触发（LT）的开关，它的行为由底层操作系统 I/O 多路复用机制决定——Linux 上是 epoll，macOS/BSD 上是 kqueue。但关键在于：Java NIO 在所有主流平台默认且仅使用水平触发语义，即使底层支持 ET（如 Linux epoll），JVM 也未提供 API 启用它，也不保证 ET 行为的一致性。
Java Selector 实际上是“逻辑水平触发”
无论底层是 epoll 还是 kqueue，Selector.select() 返回的就绪通道（SelectionKey），只要其对应文件描述符仍满足就绪条件（如 socket 接收缓冲区仍有数据、发送缓冲区仍有空间），下一次 select 就大概率再次返回该 key。这符合 LT 的语义：持续通知，直到状态改变。
原因在于：
- JVM 的 NIO 实现（如 Linux 上的
EPollSelectorImpl）在注册时默认不设EPOLLET标志，始终走 LT 路径； - 即使某些旧版 JVM 曾尝试实验性 ET 支持，也因跨平台兼容性差、易导致读写遗漏而被弃用；
-
kqueue本身没有严格对应的 ET/LT 模式，它通过EV_CLEAR（默认启用）实现类似 LT 的行为：事件被消费后需重新注册才可再次触发，而 JVM 总是依赖这一机制维持“就绪即可见”的语义。
读就绪事件在不同系统上的表现差异很小
对“读就绪（OP_READ）”，Linux epoll 和 macOS kqueue 在 Java 封装下表现高度一致：
- 客户端发来 2KB 数据，服务端调用
select()返回OP_READ； - 若只读取 1KB，缓冲区剩余 1KB，下次
select()通常立即返回同一 key —— 这是 LT 的典型表现； - 不会出现“读了一次就不通知了，等新包来才再触发”的 ET 行为；
- 即使底层 epoll 被手动配置为 ET，JVM 的 native 层也不会那样用，应用层也无从控制。
为什么 Java 不开放边缘触发？
根本原因不是技术不可行，而是工程权衡：
- 可移植性优先：kqueue 没有 EPOLLET 对等机制，强行模拟 ET 会增加复杂度与 bug 风险；
-
开发友好性：ET 要求非阻塞 + 循环读直到
EAGAIN，Java NIO 已抽象出ByteBuffer和read()方法，若强制 ET，用户需自行处理底层错误码和重试逻辑，违背 NIO 的高层抽象目标； - 实际收益有限：现代 JVM 的 selector 实现已针对高并发优化（如延迟注册、事件批量处理），LT 带来的少量重复通知在多数业务场景中并不构成瓶颈。
如果你真需要 ET 级性能
Java 生态中已有成熟替代方案，它们绕过 NIO Selector，直接对接底层 ET 语义：
-
Netty：在 Linux 上默认使用
EpollEventLoop，内部启用 ET 模式，并封装了自动循环读/写、EAGAIN处理、内存池等，开发者无需关心触发模式细节； - Vert.x：基于 Netty 或自研事件循环，同样隐式利用 ET 提升吞吐；
- JNI 直接调用 epoll：极少数高性能中间件（如某些 RPC 框架）会这么做，但属于非常规路径，维护成本高。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
