serversocketchannel 是 java nio 中支持非阻塞 accept 和 selector 多路复用的 tcp 监听通道；调用 accept() 时，有就绪连接则返回 socketchannel，否则立即返回 null，不阻塞线程，需配合非阻塞 socketchannel 实现真正异步 i/o。
ServerSocketChannel 是 Java NIO 中面向 TCP 的监听通道，与传统阻塞式 ServerSocket 相比，它支持非阻塞模式和 Selector 多路复用，是构建高并发服务器的关键组件。核心差异不在“能不能收连接”，而在于“怎么收”——非阻塞模式下，accept 不再让线程停住等待，而是立即返回结果，把控制权交还给程序逻辑。
非阻塞模式下 accept 的行为本质
调用 serverSocketChannel.accept() 时：
- 若此时有已完成三次握手的客户端连接，直接返回一个已建立的 SocketChannel 实例
- 若当前无就绪连接，立刻返回
null，线程继续向下执行，不会挂起 - 不抛异常、不阻塞、不占用线程资源，完全由程序决定何时重试或做其他事
与传统 ServerSocket 的关键区别
传统 ServerSocket 的 accept() 总是阻塞的：线程卡在那，直到新连接到来才唤醒。这导致单线程只能串行处理连接，多线程又面临资源开销大、上下文切换频繁的问题。
ServerSocketChannel 配合 configureBlocking(false) 后：
- 单线程可轮询多个通道（如配合 Selector），避免线程闲置
- 连接接收逻辑可嵌入统一事件循环，比如在处理完一批读写后顺带检查是否有新连接
- 天然适配异步编程模型，为后续注册 OP_ACCEPT 事件打下基础
典型非阻塞连接接收流程（无 Selector 场景）
即使不使用 Selector，也能体现非阻塞特性：
- 先调用
serverSocketChannel.configureBlocking(false) - 在 while 循环中反复调用
accept()，判断返回值是否为 null - 为防空转耗尽 CPU，通常加入短时休眠（如
Thread.sleep(10)）或让出时间片 - 一旦获得非 null 的 SocketChannel，立即对其配置非阻塞、分配缓冲区、并开始读写管理
为什么非阻塞 accept 必须搭配非阻塞 SocketChannel？
服务端拿到新连接后，若仍用阻塞方式读写该 SocketChannel，整个线程还是会卡在 read/write 上。所以实际使用中：
- 新创建的 SocketChannel 也必须调用
configureBlocking(false) - 否则无法实现单线程管理多个连接的目标
- 后续读写需自行处理
read()返回 0 或 -1 的情况（无数据 / 连接关闭），不能依赖阻塞语义
