空轮询bug本质是jdk对linux epoll封装缺陷所致，导致selector.select()本该阻塞却频繁返回0，引发cpu 100%空转；仅限linux平台，因windows用iocp、macos用kqueue无此问题。
这个问题核心不在 JVM 本身，而在于 JDK 对 Linux epoll 的封装逻辑缺陷——它不是 Java 语言层面的 bug，而是 JDK 在特定内核行为下未能正确处理就绪事件状态，导致 Selector.select() 频繁返回 0，引发线程空转、CPU 持续 100%。
空轮询的本质：epoll 被误唤醒 + JDK 状态判断失效
Linux 内核中，当 TCP 连接被对端异常关闭（如发送 RST）、或文件描述符处于 POLLHUP/POLLERR 状态时，epoll_wait 可能返回就绪事件数为 0，但依然唤醒用户态。JDK 的 EPollSelectorImpl 未严格校验内核返回的真实就绪链表是否为空，仅依赖返回值做判断，于是把“无事件但被唤醒”错误识别为“应继续轮询”，从而跳过阻塞，进入死循环。
典型触发链路：
- 服务端注册
OP_READ后读完数据，主动清除了 interest ops - 客户端突然断连（RST），内核产生
POLLHUP -
epoll_wait返回 0，JDK 误认为“需重试”，不阻塞直接返回 - 业务线程反复调用
select()，CPU 拉满
为什么只在 Linux 上出现
因为该问题根植于 epoll 的行为特性与 JDK 实现耦合：
- Windows 使用 IOCP，macOS 使用 kqueue，二者事件通知机制稳定，无此类误唤醒逻辑
- Linux 不同内核版本（尤其 2.6.17–2.6.32）对
POLLHUP的映射和就绪判定存在差异，加剧了 JDK 判断失准 - JDK 官方虽多次标记修复（如 Bug ID 6403933、6670302），但截至 JDK 17 仍未彻底根治，仅通过优化降低触发概率
Netty 的四层防御：检测 + 超时 + 阈值 + 重建
Netty 不等 JDK 修复，而是在线程级主动干预 NIO 事件循环：
-
计数监控：每次
select()返回后递增selectCnt；若返回 0 且非超时/非唤醒所致，记为一次空轮询 - 超时兜底：每次 select 带动态超时（基于最近定时任务延迟），超时返回即重置计数，避免误判
-
阈值触发：默认累计 512 次空轮询（可通过
io.netty.selectorAutoRebuildThreshold调整），判定进入死循环状态 - 无缝重建：新建 Selector → 原 Channel 和 SelectionKey 迁移（保留 attachment、interestOps）→ 关闭旧 Selector → 切换引用，全程无事件丢失、不中断上层逻辑
原生 NIO 的规避难点
手动实现类似 Netty 的防护非常脆弱：
- 需自行维护计数器、超时逻辑、重建流程，极易遗漏边界（如迁移时 key 有效性校验、多线程并发注册）
- 重建过程若未清理已 cancel 的 key，会触发
CancelledKeyException - 阈值设置无标准：太小易误重建，太大则 CPU 已长期飙高
- 无法绕过 JDK 底层 epoll 封装缺陷，只能“事后补救”，不能从源头抑制误唤醒
