NIO场景下为OP_ACCEPT与OP_READ分别使用不同Selector的问题咨询

问题根因 #

这是Java NIO多Selector线程协作的经典问题，最高发的两个核心原因如下：

1. Selector注册操作与select()调用的线程安全冲突
   负责处理OP_READ的Selector所在线程如果已经阻塞在selector.select()调用上，你在accept线程执行sc.register(selector, SelectionKey.OP_READ, c)时，注册操作会被挂起直到select()方法返回，而没有事件触发时select()会一直阻塞，形成死等：注册要等select返回，select要等注册完成后的事件触发。
2. SSL握手阶段耗尽了客户端的首批数据
   你在accept线程同步执行doHandshake(sc, e)时，已经将SocketChannel中所有可读数据全部读取完成用于握手，握手完成后如果客户端没有新数据发送，自然不会触发OP_READ事件。

定位步骤 #

• 在注册OP_READ的代码后新增一行selector.wakeup()，测试问题是否消失，如果消失可确认是线程冲突问题。
• 新增日志打印doHandshake方法中读取的字节数，以及注册完成后调用sc.read(buffer)的返回值，如果返回值>0说明确实有数据在握手阶段被读走，没有剩余数据触发OP_READ。

修复方案 #

针对Selector线程冲突的修复 #

所有跨线程给Selector注册通道的操作，注册完成后必须主动唤醒Selector：

sc.register(selector, SelectionKey.OP_READ, c);
selector.wakeup(); // 新增该行，唤醒阻塞的select()调用，让注册的事件被Selector感知
System.out.println("Registered socket channel to selector");

读Selector线程如果是循环调用select()的场景，wakeup只会让本次select立刻返回，下次循环的select()会正常监听新注册的OP_READ事件，不会产生额外性能损耗。

针对握手耗数据的修复 #

如果确认是握手阶段把客户端首批数据读走了，可二选一处理：

• 握手完成后主动触发一次ClientHandler的读逻辑，手动消费掉SocketChannel中剩余的已到达数据，再等待后续OP_READ事件。
• 把SSL握手逻辑迁移到读Selector所在的线程执行，握手完成前先注册OP_READ/OP_WRITE事件驱动握手流程，避免跨线程读写SocketChannel导致的数据消费异常。

内容的提问来源于stack exchange，提问作者arcticlights