面经策

Netty 如何解决 JDK NIO 中的空轮询 Bug？ ​

  • 标签：Netty、后端

🏛 业务架构师 ​

背景：JDK NIO 的 Selector 在 Linux 上偶发 select() 提前返回但没有任何就绪事件——空轮询 bug（JDK 官方未彻底修复）。后果是事件循环线程死循环空转，CPU 打满 100%，业务表现是服务突然卡死但进程还活着。

Netty 的解法很"工程务实"：

  • 每次 select 计时，若在阈值内（默认 512ms）连续发生空轮询达到次数上限（默认 512 次），判定触发了 bug；
  • 触发后新建一个 Selector，把旧 Selector 上所有 Channel 的注册关系逐个迁移到新 Selector，废弃旧的——用一个新"挂号窗口"绕开出问题的那个，业务连接一个不丢，服务继续跑。

我讲这个案例的架构启示，比机制本身更有价值：

  1. 依赖不可控时的自愈设计：JDK 的 bug 你修不了、发布节奏也不归你管，Netty 选择"检测 + 重建 + 无缝迁移"的自愈路径。业务系统同理：依赖的第三方有已知缺陷时，与其等待不如设计旁路和自愈，把故障时间从"等修复"压到"自动绕过"；
  2. 问题的量化判定：用"次数阈值 + 时间阈值"的组合判定，而不是单次异常就动作——避免误判引发无谓重建。告警系统设计里"连续 N 次超阈值才告警"是同一思想，阈值化是抑制抖动的通用手法；
  3. 迁移的原子性与审计：重建过程对所有 channel 重新注册，确保不漏。做任何"热替换"类设计（数据源切换、配置热更）都要回答"替换瞬间的存量怎么办"。

一句话：Netty 教的不是 NIO，是"在不可靠的地基上盖出可靠的房子"的工程方法论。

🏗 系统架构师 ​

先说 bug 本身：JDK NIO 的 Selector 在某些 Linux 内核版本上，select() 本应阻塞等待事件，却异常立即返回 0，且循环里没有 break 条件的话就变成死循环——CPU 空转到 100%，这就是空轮询 bug。

Netty 的解决方案（防御性重建）：NioEventLoop 每轮 select 记录耗时，发现一次 select 只返回 0 个事件时累加计数；在512ms 内发生多次（默认阈值 SELECTOR_AUTO_REBUILD_THRESHOLD）空轮询，就判定踩中 bug，动作是：新建一个 Selector，把旧 Selector 上所有 Channel 的注册事件逐个迁移到新 Selector 上，废弃旧的。整个过程对上层无感，事件处理逻辑不中断。

架构启发（这题的价值所在）：

  • 对不可控的底层依赖（内核/JDK bug），做检测 + 自愈的熔断式兜底，而不是等待官方修复——Netty 还顺带用 timeoutMillis 校正 select 阻塞时间、优化 selectStrategy 避免不必要的唤醒；
  • 这是我评估基础库成熟度的标准：不在于没有 bug，而在于对异常场景的防御深度。自研中间件时我都会问一句：依赖坏了，我的模块能不能自恢复？

💻 全栈开发专家 ​

Bug 现象：Linux JDK NIO 的 Selector.select() 在 epoll 上偶发不阻塞立即返回 0，且循环里没有就绪事件——死循环空转，CPU 100%。这是老内核 epoll 对已销毁连接/半关闭连接处理的缺陷触发的问题，JDK 多年没修。

Netty 的规避方案（自动，无需业务感知）：

  1. 每次事件循环统计"空轮询"：select 返回 0 且没处理任何事件的次数累加；
  2. 某个 EventLoop 的计数在阈值内（默认 SELECTOR_AUTO_REBUILD_THRESHOLD = 512）正常；
  3. 超过阈值 → 判定踩中 bug → 新建一个 Selector，把旧 Selector 上注册的所有 Channel 连同感兴趣事件迁移到新 Selector，然后废弃旧的。相当于"换一个没问题的 selector"绕开内核状态。
java
// NioEventLoop 源码逻辑（示意）
private void select() {
    long t = System.nanoTime();
    if (selector.select() == 0 && !hasTasks()) {
        if (System.nanoTime() - t < timeoutMillis) {
            selectCnt++;                 // 疑似空轮询
            if (selectCnt >= 512) rebuildSelector();  // 重建
        }
    }
}

给我的启示（面试升华）：这就是我不裸用 NIO 的核心理由之一——Netty 把平台 bug、半包、内存池、线程模型这些脏活都兜住了。排查这类 CPU 100% 问题：top -Hp + jstack 能看到线程卡在 EPollArrayWrapper.epollWait 附近的死循环。