nio变量并发问题隐蔽，因selector单线程轮询与业务多线程协作时易出现buffer复用错乱、selectionkey误操作、channel跨线程配置三类错误；须将状态绑定到selectionkey.attachment()并遵循事件生命周期管理。

Java NIO非阻塞模型的核心，不是单纯让read()不卡住，而是通过“事件就绪才处理+单线程轮询多个通道”的机制，把连接数和线程数彻底解耦。变量并发难点（比如共享缓冲区、SelectionKey状态竞争、Handler执行中修改Channel配置）往往不是多线程争抢本身，而是对NIO事件生命周期理解偏差导致的误操作。

为什么变量并发问题在NIO里特别隐蔽

NIO服务端通常用1个Selector线程轮询成千上万Channel，但业务逻辑（如解码、响应组装）常被分发到其他线程池执行。这时容易踩三个坑：

• Buffer复用错乱：多个Channel共用同一块ByteBuffer（尤其堆外DirectBuffer），一个Channel还没读完，另一个就clear()重置了position/limit；
• SelectionKey重复注册或取消：在业务线程里调用key.cancel()或channel.register(selector, ops)，而Selector线程正在select()或遍历selectedKeys()，引发CancelledKeyException或漏事件；
• Channel配置跨线程变更：在IO线程外调用socketChannel.configureBlocking(true)或setOption()，可能触发未定义行为，尤其在Linux epoll下会破坏事件注册状态。

关键变量必须绑定到事件生命周期

NIO没有“每个连接一个对象”的天然封装，所有状态需显式管理。推荐做法是把关键变量封装进SelectionKey.attachment()，并严格遵循“谁注册、谁清理”原则：

• accept事件触发时，创建SocketChannel后立即configureBlocking(false)，再注册到Selector，并用key.attach(new ConnectionContext())挂载专属上下文；
• read/write事件触发时，从key.attachment()取出上下文，用它持有的独立ByteBuffer（如ByteBuffer.allocateDirect(8192)）进行读写；
• 连接关闭时，在key.isValid()为true的前提下，先清理attachment中的资源（如buffer.clear()、close()业务句柄），再key.cancel()。

Selector线程与业务线程的安全协作模式

避免在业务线程中直接操作Channel或Key，改用“事件通知+延迟执行”：

• 需要异步写响应？不要在业务线程调channel.write()，而是将数据包放入该连接上下文的ConcurrentLinkedQueue<bytebuffer></bytebuffer>，然后key.interestOps(SelectionKey.OP_READ | SelectionKey.OP_WRITE)唤醒Selector线程；
• 需要关闭连接？在业务线程里只标记context.setClosing(true)，由Selector线程在下一次select()后检查标记并执行channel.close()；
• 需要动态调整读写缓冲区大小？不直接改channel，而是在上下文中更新期望值，由IO线程在下次读写前按需compact()或flip()缓冲区。

实战中必须规避的典型误操作

这些写法看似合理，实则破坏NIO事件驱动契约：

• 在业务线程中调用selector.wakeup()后立刻select()——wakeup只是中断当前阻塞，若不在Selector线程内调用select()，事件不会被处理；
• 用synchronized(ConnectionContext.class)锁整个类来保护多个连接——造成串行化，吞吐量归零；应改用每个上下文实例自己的ReentrantLock，且只锁必要字段；
• 把SelectionKey存入全局Map供业务线程随时取用——Key可能已被cancel或失效，正确方式是业务线程持有ConnectionContext引用，由它代理访问有效Key。