Selector空轮询Bug核心表现是Linux下NIO线程CPU持续100%、select()频繁返回0且无日志异常；Netty通过带超时select、空轮询计数、阈值触发（默认512次）和无缝重建Selector四步机制主动修复。
Java 中 Selector 空轮询 Bug 的核心表现是：Linux 下 NIO 线程 CPU 持续 100%，select() 频繁返回 0，但无异常日志、无连接断开提示、服务响应变慢或假死。它不是代码逻辑错误，而是 JDK 在 epoll 实现层的底层缺陷，需从现象识别、线程定位、诱因分析到机制修复分步处理。
怎么快速确认是不是空轮询？
关键看三点：
-
CPU 持续 100% 且集中在 NioEventLoop 或 Selector 所在线程：用
top -H -p <pid></pid>找出高占用线程 ID，再用printf "%x\n" <tid></tid>转为十六进制，用jstack <pid> | grep -A 20 <hex-tid></hex-tid></pid>抓栈 —— 若看到反复在NioEventLoop.select()或EPollSelectorImpl.doSelect()循环，基本锁定； -
select 返回值稳定为 0，且无 wakeup、无任务、无超时：在 jstack 栈中若看到循环体里
selectedKeys == 0并不断递增计数器（如selectCnt），就是典型空轮询特征； - 仅在 Linux 生产环境复现，Windows/macOS 正常：该 Bug 与内核 epoll 行为强相关，若测试机是 macOS、生产是 CentOS/Alibaba Cloud Linux，就高度可疑。
常见触发场景有哪些？
不是随机发生，多由特定网络行为放大内核边界问题：
- 高频短连接（如 HTTP/1.1 未复用、RPC 单次调用即断连），导致大量 fd 快速创建 + 关闭，epoll 内部状态同步紊乱；
- 客户端异常断连（RST 包、强制 kill 进程），服务端 channel 收到 POLLHUP 但 interestOps 为 0，JDK 误判为“有事件”却无实际 OP_READ/OP_WRITE 可派发；
- Channel 关闭后未及时 cancel SelectionKey，残留无效 key 在 selector.keys() 中，加剧 epoll_wait 返回异常；
- 自定义心跳或空闲检测逻辑不严谨，频繁调用
selector.wakeup()又无实际事件，干扰 select 阻塞语义。
原生 NIO 怎么临时规避？
不推荐长期使用，但可应急或用于验证：
立即学习“Java免费学习笔记（深入）”；
- 给
select(timeout)设置合理超时（如 500ms），避免无限阻塞也防止纯空转； - 手动维护空轮询计数器，连续超过阈值（如 200 次）后主动重建 Selector —— 注意迁移 Channel 时要遍历 valid keys，跳过已 cancel 的 key，否则抛
CancelledKeyException； - 每次读写操作后检查 key 有效性：
if (!key.isValid()) continue;，注册前确保 interestOps 不为 0； - 连接关闭时务必调用
key.cancel()+channel.close()，并显式selector.selectNow()清理状态。
Netty 是怎么根治的？
Netty 不依赖 JDK 修复，而是在 NioEventLoop.select() 中嵌入四层防御：
- 带超时 select：每次调用都带动态计算的 timeout（基于最近定时任务），超时返回即重置计数器，区分“真超时”和“假唤醒”；
-
空轮询计数：仅当
selectedKeys == 0且非超时、非唤醒、无待执行任务时，才累加selectCnt； -
阈值触发重建：默认
io.netty.selectorAutoRebuildThreshold=512，达阈值即判定进入 epoll 死循环； - 无缝迁移重建：新建 Selector → 原 key 逐个迁移（保留 attachment、interestOps）→ 关闭旧 Selector → 切换引用，整个过程由单线程完成，不丢事件、不重复注册。
该机制默认开启，无需额外编码。可通过 JVM 参数调整阈值：-Dio.netty.selectorAutoRebuildThreshold=256，但不建议设低于 3（Netty 会自动禁用）。
