必须同时将ServerSocketChannel和SocketChannel设为非阻塞：先调用serverSocketChannel.configureBlocking(false)，accept后立即对返回的socketChannel调用configureBlocking(false)，否则read/write仍会阻塞线程。

SocketChannel 和 ServerSocketChannel 的非阻塞配置不是“开个开关”就完事，而是整套 I/O 模型切换的前提。关键在于：必须显式调用 configureBlocking(false)，且两者要同步设置——ServerSocketChannel 不阻塞，只解决“收连接不卡线程”；新 Accept 出来的 SocketChannel 若仍阻塞，读写照样会把线程拖住。

ServerSocketChannel 非阻塞接收连接

它负责监听端口、接受新连接。默认是阻塞的，需主动关闭阻塞行为：

• 调用 serverSocketChannel.configureBlocking(false)，这是强制步骤，不能省略
• 之后调用 accept() 就不再挂起线程：有就绪连接返回 SocketChannel，没有就立刻返回 null
• 不能在 while(true) 中裸调 accept()，否则 CPU 空转；建议搭配短时休眠（如 Thread.sleep(10)）或交由 Selector 统一调度
• 若使用 Selector，需注册 OP_ACCEPT 事件，等就绪后再调用 accept()

SocketChannel 必须同步设为非阻塞

ServerSocketChannel.accept() 返回的 SocketChannel 默认仍是阻塞模式，这点极易被忽略：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 拿到新 SocketChannel 后，**立即**执行 socketChannel.configureBlocking(false)
• 否则后续的 read() 或 write() 仍会阻塞，单线程管理多连接的目标就彻底失效
• 非阻塞 read() 可能返回 0（无数据）、-1（对端关闭）或正数（读到字节），代码必须显式判断这些情况，不能依赖“等数据来”的语义
• 建议同时配置 TCP 选项，如 socketChannel.socket().setKeepAlive(true)，增强连接稳定性

典型配合 Selector 的完整流程

这才是生产环境推荐的做法，真正发挥 NIO 多路复用优势：

立即学习“Java免费学习笔记（深入）”；

• 创建 Selector：Selector selector = Selector.open();
• ServerSocketChannel 配置非阻塞，并注册 OP_ACCEPT：serverChannel.register(selector, SelectionKey.OP_ACCEPT);
• 循环调用 selector.select() 等待事件就绪（可设超时避免无限等待）
• 遍历 selectedKeys，对 OP_ACCEPT 事件调用 accept()，得到 SocketChannel 后立即设为非阻塞，并注册 OP_READ
• 对 OP_READ 事件，用 ByteBuffer 读取数据，处理业务逻辑，无需新建线程

常见误区提醒

几个高频踩坑点：

• 只设 ServerSocketChannel 非阻塞，忘了 SocketChannel：结果 accept 不卡，但第一个 read 就卡死整个线程
• 非阻塞下仍用 while(sc.read(...) > 0) 循环读：read() 返回 0 是常态，不是错误，盲目循环会导致 CPU 占用飙升
• 没处理 read() 返回 -1：说明客户端已关闭连接，应主动 close() 对应的 SocketChannel 并取消 key 注册
• ByteBuffer 没 flip/clear 切换读写模式：导致数据读不到或写乱，非阻塞场景下缓冲区管理更需严谨