Selector 阻塞是正常设计，所谓“假死”实为空轮询或 select 长期不返回；应改用带超时的 select(timeout)，正确使用 wakeup()，监控并重建空轮询 selector，且事件处理须异步非阻塞。
Java NIO 中 Selector 阻塞本身不是 bug，而是设计行为——它本就该等事件；所谓“线程假死”，通常指两种情况：一是 空轮询导致 CPU 100%，线程看似在跑却没干正事；二是 select() 长期不返回，业务无法响应（如被唤醒机制遗漏、外部中断失效）。解决重点不在“不让它阻塞”，而在“让阻塞可控、可干预、可兜底”。
用带超时的 select(timeout) 替代无参 select()
无参 select() 在无事件时会无限等待，一旦 wakeup 失效或内核通知异常，线程就卡住。改用带毫秒超时的版本，能确保循环始终推进：
- 设置合理 timeout（如 100–500ms），既避免高频空转，又保证响应及时
- 每次返回后检查是否真有事件：
if (readyCount > 0)再处理 selectedKeys - 即使超时返回 0，也能插入健康检查、日志采样或轻量任务（如心跳检测）
必须正确使用 wakeup() 并确保调用时机可靠
selector.wakeup() 是打破阻塞的合法手段，但容易误用：
- 只在另一个线程需要立即触发事件处理时调用（如新连接注册、关闭信号到达）
- 避免在 select() 正在执行时重复调用——多次 wakeup 只生效一次，且可能干扰状态
- 确保 wakeup 调用方与 selector 所在线程内存可见性一致（如用 volatile 标记状态，或通过队列协调）
主动监控空轮询并重建 Selector
Linux epoll 的“假唤醒”缺陷会导致 select(timeout) 频繁返回 0 且耗时极短（远小于设定 timeout），这是空轮询典型特征：
立即学习“Java免费学习笔记（深入）”；
- 维护一个计数器，在每次 select 返回 0 且非 wakeup 触发、无 pending 任务时递增
- 达到阈值（如 Netty 默认 512 次）即判定为陷入空轮询，记录告警并执行 selector 重建
- 重建步骤：关闭旧 selector → 创建新 selector → 将所有 channel 重新注册（注意保留 interestOps）
不要在事件循环中做耗时或阻塞操作
看起来是“Selector 假死”，实际常因业务代码拖垮整个循环：
- OP_READ 处理中不能直接解析大 JSON 或写磁盘——应交由业务线程池异步处理
- OP_WRITE 触发后若缓冲区未清空，需持续关注 OP_WRITE 就绪，但不能在循环里死等
- 所有 I/O 操作必须基于非阻塞 Channel，禁止在事件处理器中调用
socket.getInputStream().read()这类 BIO 方法
