Selector空轮询Bug本质是Linux epoll底层缺陷导致select()无故返回0，引发CPU 100%死循环；Netty通过计数监控、超时兜底、阈值触发（默认512次）和无缝重建Selector四步机制主动修复。
客户端连接瞬间暴增时，Selector 空转崩溃本质是“伪就绪+无效唤醒”叠加导致的 CPU 100% 和事件处理失序。这不是配置错误，而是 Linux epoll 底层 bug（JDK-6403933）在高并发短连接场景下的必然表现——epoll_wait 返回后就绪链表为空，但 JDK 的 Selector 实现误判为有事件，触发无限 select 循环。
用带阈值的空轮询检测机制主动拦截
不能依赖 select() 是否阻塞，而要靠计数识别异常模式：
- 每次 select() 返回 0（无就绪通道），就累加空轮询计数器
- 连续超过 512 次（Netty 默认阈值）即判定为空轮询 bug 触发
- 立即重建 Selector：创建新实例，将所有有效 Channel 迁移过去，再关闭旧 Selector
- 迁移过程需同步操作，避免 channel 注册期间丢失 accept 或 read 事件
拆分 Selector 实例，分散单点压力
单个 Selector 承载全部连接，在连接数突增时会加剧锁竞争与遍历开销：
- 按 CPU 核心数或预期并发量，预先启动多个 EventLoop 线程（如 4~8 个）
- 每个线程持有独立 Selector，并只注册属于它的那部分连接
- 新连接通过轮询或一致性哈希分配到某个 EventLoop，避免热点集中
- ServerSocketChannel 仍只需注册 OP_ACCEPT，由它触发后分发给具体 Worker
动态管理 interest ops，减少无效唤醒源
大量连接建立后若统一注册 OP_READ，但部分连接尚未发数据，就会制造大量“就绪但无实际数据”的虚假事件：
立即学习“Java免费学习笔记（深入）”；
- 新连接 accept 后，仅注册 OP_READ；确认有数据可读再维持，否则不额外监听
- 写操作中若 write() 返回 0（内核缓冲区满），才临时追加 OP_WRITE；写完立即移除
- 连接断开、异常 IOException 或远程 FIN 到来时，必须调用 key.cancel() 并 close channel
- 每次 select() 后遍历 selectedKeys，必须用 iterator.remove() 清理已处理 key，防止重复触发
启用 EPOLL 提升底层效率
JVM 默认可能使用 SELECT/POLL，而 Linux 上应强制走 epoll：
- 启动参数加入：-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider
- 确保 JDK 版本 ≥ 8u231 或 ≥ 11，避免早期 epoll 实现缺陷
- 注意：该设置仅对 Linux 生效，Windows/macOS 不受影响
