Java Selector wakeup 调用早于 select 时为什么仍会阻塞

我排查 Java NIO 事件循环时，最容易误判的一句话就是：“明明先调用了 wakeup()，后面的 select() 为什么还在等？”按 API 语义，如果唤醒发生在选择操作开始前，下一次 select() 或 select(timeout) 应该立即返回，返回值也可能是 0。仍然阻塞，通常不是 wakeup() 失效，而是唤醒许可已经被别的选择操作消费、调用的不是同一个 Selector，或中间插入了会清除唤醒效果的 selectNow()。

先记结论：wakeup() 是一次性的选择操作唤醒信号，不是可累计的消息队列。先调用再 select() 本身不会导致阻塞；先查 Selector 身份、调用时序，以及中间是否出现 selectNow()。

wakeup 到底记住了什么

可以把它理解成 Selector 上的一枚“一次性通行证”。选择线程正在阻塞时，其他线程调用 wakeup()，当前的 select() 会尽快返回；选择线程尚未进入 select() 时，下一次阻塞式选择会立即返回。这个返回只说明等待被打断，不说明有通道已经就绪，所以返回值可能是 0。

通行证在一次选择操作中被消耗。官方 API 还特别说明，调用 selectNow() 会清除此前 wakeup() 的效果。因此下面的结构会把提前唤醒“吃掉”，最后的阻塞是符合语义的：

selector.wakeup();
selector.selectNow(); // 中文注释：非阻塞选择会清除此前 wakeup 的效果
selector.select();    // 中文注释：此处已没有待消费的唤醒许可，可能正常阻塞

先 wakeup 后 select 仍阻塞，先查这四种时序

我通常先给每个 Selector 打一个身份标记，再给 wakeup、select、selectNow 记录线程名和纳秒时间。不要只看日志的自然顺序：多线程日志可能交错，而且“同一个端口”不等于“同一个 Selector”。

还有一个常见误区：wakeup() 不会替你修改 interest set，也不会把 Runnable、连接或关闭命令塞进 Selector。它只负责让选择线程重新获得执行机会，真正的业务意图仍要放进共享队列或其他线程安全状态。

用任务队列把唤醒写成稳定的事件循环

提交线程先入队，再唤醒同一个 Selector；选择线程在进入阻塞前和返回后都处理一次队列。这样即使唤醒发生在 select() 前，也只是让本轮快速返回，不会丢掉任务。

final Selector selector = Selector.open();
final Queue tasks = new ConcurrentLinkedQueue();

void submit(Runnable task) {
    tasks.add(task);       // 中文注释：先发布任务，避免 wakeup 只留下空信号
    selector.wakeup();     // 中文注释：让可能阻塞的选择线程尽快处理队列
}

void loop() throws IOException {
    while (selector.isOpen()) {
        Runnable task;
        while ((task = tasks.poll()) != null) {
            task.run();     // 中文注释：在拥有 Selector 的线程执行注册或修改
        }

        int ready = selector.select();
        while ((task = tasks.poll()) != null) {
            task.run();     // 中文注释：select 返回 0 也要处理被唤醒的任务
        }
        if (ready == 0) {
            continue;       // 中文注释：0 只表示没有就绪 key，不表示 wakeup 失败
        }
        // 中文注释：这里再遍历 selectedKeys，并处理真实 I/O 事件
    }
}

这个模式的关键不是“保证 select 永不阻塞”，而是把阻塞变成可解释的等待点：队列有任务时由 wakeup() 打断，没有任务且没有就绪通道时重新等待。注册、取消和 interestOps 修改也集中在选择线程执行，排查起来会比多个线程各自 select 清楚。

排查时别漏掉这份最小清单

• 给 Selector 记录稳定的对象标识，确认 wakeup() 和 select() 指向同一实例。
• 记录每次选择调用的开始、返回值、线程名和等待方式，特别搜索中间的 selectNow()。
• 把“唤醒”和“任务”分开：唤醒只是通知选择线程，任务要由队列或状态承载。
• 检查是否存在两个选择循环；同一 Selector 不要让多个线程同时承担事件消费职责。

常见问题

wakeup 调用后 select 返回 0 是异常吗？

不是。唤醒和通道就绪是两件事；没有就绪 key 时返回 0 完全可能，应用应继续处理任务队列。

能不能连续调用两次 wakeup 让两轮 select 都不阻塞？

不能把它当作可累计计数器。连续唤醒通常只服务于尚未返回的选择操作，下一轮是否立即返回要看具体时序，业务信号应放入队列。

select(timeout) 也会受提前 wakeup 影响吗？

会。只要是尚未返回的阻塞式选择，wakeup() 都会使其尽快返回；超时只是另一个返回条件。