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

【核心定义】
Netty 通过 重建 Selector 机制，检测并规避 JDK NIO 中因 Selector.select() 在无就绪事件时被意外唤醒（返回 0）导致的 CPU 100% 空轮询 Bug。

【关键要点】

问题定位：JDK NIO 的 Selector.select() 在某些场景下（如 Linux 内核 epoll 实现缺陷）可能在没有就绪事件时立即返回 0，而非阻塞等待，导致循环空转、CPU 占用飙升。
检测机制：Netty 在 NioEventLoop 中记录 select() 调用次数与任务执行时间，若发现短时间内（如一个周期内）连续触发 select() 但无实际 I/O 事件处理，则判定为空轮询。
修复策略：触发空轮询阈值后，Netty 立即创建新的 Selector，将原 Selector 上注册的 Channel 重新注册到新 Selector，并关闭旧 Selector，从而恢复正常的阻塞等待逻辑。

【深度推导/细节】
空轮询触发逻辑拆解：

Step 3：当 selectCnt 超过阈值（默认 512），触发重建逻辑：

// 源码逻辑简化
if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 && selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
    rebuildSelector(); // 重建 Selector
}

Step 4：rebuildSelector() 创建新 Selector，遍历旧 Selector 的所有 SelectionKey，将对应 Channel 重新注册到新 Selector，并保持原有 interestOps 配置。
Step 5：关闭旧 Selector，后续事件轮询基于新 Selector 执行，避免内核态缺陷持续触发。

阈值设计合理性：

【关联/对比】

与 JDK NIO 原生方案的对比：JDK 自身在后续版本（如 JDK 11）中逐步修复了部分 epoll 空轮询问题，但 Netty 的机制是向前兼容的防御性设计，即使运行在有缺陷的 JDK 版本上也能保证稳定性。
与 Netty 其他故障恢复机制的关联：类似 Channel 异常关闭重连、线程池异常处理，Netty 将“重建”作为核心恢复模式，体现其自我修复的设计哲学。

『面试官追问』

空轮询检测的具体时间窗口如何计算？
Netty 通过 deadlineNanos 记录单次事件循环的截止时间，若 select() 提前返回且未到截止时间，则判定为可疑空轮询。
重建 Selector 期间如何处理已在途的 I/O 事件？
重建过程在 EventLoop 线程内同步执行，期间暂停事件处理，但耗时极短（仅注册操作），且旧 Selector 关闭前会取消未处理事件，由新 Selector 重新触发。
除了空轮询，Netty 还优化了 JDK NIO 的哪些问题？
- 内存泄漏检测（ResourceLeakDetector）
- ByteBuffer 池化（PooledByteBufAllocator）
- 线程模型优化（单线程处理 Channel 生命周期）

【线程安全与版本差异】

线程安全：Selector 重建由 EventLoop 线程独立完成，无需外部同步。
版本差异：
- Netty 4.x 统一引入该机制，阈值可通过 io.netty.selectorAutoRebuildThreshold 系统参数调整。
- JDK 1.6/1.7 的 NIO 空轮询 Bug 最显著，Netty 3.x 已开始提供规避方案，但 4.x 将其标准化为内置防御逻辑。

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