Selector空轮询Bug是JDK NIO在Linux上因epoll内核行为异常导致select()无故返回0，引发CPU 100%死循环；Netty通过计数监控、超时兜底、阈值触发（默认512次）和无缝重建Selector四步机制主动解决。
什么是 Selector 空轮询 Bug
Selector 空轮询 Bug 是 JDK NIO 在 Linux 平台上的一个底层缺陷：本该阻塞等待 I/O 事件的 selector.select() 方法，会无故立即返回 0（即无就绪通道），导致业务线程陷入无限循环。它不抛异常、不打印错误日志，只让 CPU 持续飙到 100%，服务响应停滞甚至假死。
为什么只在 Linux 上爆发
该 Bug 根植于 JDK 对不同操作系统的 NIO 实现差异：
- Linux 使用 epoll，其内核行为在某些边界条件下（如并发关闭/新建连接、POLLHUP 未被正确映射）会错误唤醒用户态 Selector
- Windows 使用 IOCP，macOS 使用 kqueue，二者均无此问题
- JDK 官方虽多次标注修复（如 Bug ID 6403933），但截至 JDK 17 仍未根治，仅降低触发概率
Netty 的四步防御机制
Netty 不依赖 JDK 修复，而是主动检测 + 主动重建，核心逻辑嵌入在 NioEventLoop.select() 中：
- 计数监控：每次 select 返回后递增 selectCnt；若返回值为 0 且非超时/非唤醒所致，视为一次“空轮询”
- 超时兜底：每次 select 带有动态计算的超时时间（基于最近定时任务），超时返回即重置 selectCnt = 1
- 阈值触发：当 selectCnt 累计达到默认 512 次（可通过 io.netty.selectorAutoRebuildThreshold 调整），判定进入 epoll 死循环状态
- 无缝重建：新建 Selector → 将原注册的所有 Channel 和 SelectionKey 迁移过去 → 关闭旧 Selector → 切换引用，全程对上层透明
关键细节与注意事项
这个修复不是“重启 selector”那么简单，它规避了几个隐藏风险：
- 迁移过程确保 Channel 不丢失、不重复注册，避免 CancelledKeyException
- 重建由单线程 NioEventLoop 自主发起，避免多线程竞争 Selector 状态
- 若阈值设为小于 3（如 0 或 2），Netty 会自动禁用该机制，需确认配置生效
- 即便重建成功，也建议配合监控（如 jstack 抓取 NioEventLoop 线程栈）定位原始诱因，例如异常连接风暴或未 clean 的 channel
