java nio非阻塞通信核心是channel+buffer+selector同步非阻塞模型，需显式设configureblocking(false)，通过selector轮询就绪事件，读写需配合buffer状态与返回值处理，避免忙等、滥用op_write及buffer误用。
Java NIO 实现非阻塞网络通信，核心在于用 Channel + Buffer + Selector 替代传统 BIO 的流式阻塞模型，让单个线程能高效管理成百上千的连接。它不是“异步回调”（如 Netty 封装后的那种），而是同步非阻塞——调用不挂起，但需主动检查就绪状态。
设置通道为非阻塞模式
这是所有非阻塞操作的前提。无论是服务端还是客户端通道，都必须显式关闭阻塞行为：
-
ServerSocketChannel：创建后调用
configureBlocking(false)，否则accept()会一直阻塞 -
SocketChannel：同样需设为非阻塞；
connect()调用后立即返回，需用finishConnect()循环检测是否连上 - 注意：一旦设为非阻塞，所有 I/O 操作（
read()、write()）都变成“尽力而为”——可能读 0 字节、写不全、或抛出IOException（如 Linux 的EAGAIN），程序必须自己处理这些情况
用 Selector 管理多个通道
Selector 是实现多路复用的关键。它背后依赖操作系统级的 I/O 多路复用机制（Linux 是 epoll，Windows 是 IOCP 封装），让一个线程轮询监听多个 Channel 的事件：
- 每个 Channel 注册到 Selector 时，要指定感兴趣的事件类型：
OP_ACCEPT（服务端）、OP_CONNECT（客户端）、OP_READ、OP_WRITE - 注册后不能直接操作 Channel，一切都要通过
SelectionKey关联的事件来驱动 - 典型循环是调用
selector.select()（阻塞等待）或selectNow()（立即返回），再遍历selectedKeys()集合处理就绪事件
事件驱动的数据读写流程
非阻塞读写不是“一次调用搞定”，而是围绕 Buffer 状态和 Channel 就绪性反复协作：
-
读数据：当
key.isReadable()为真，从对应 SocketChannel 调用read(buffer)；若返回 -1 表示对端关闭，返回 0 表示暂无数据（不是错误！），需等下次就绪再试 -
写数据：通常先将数据写入 Buffer，然后调用
write()；但非阻塞写可能只写出部分字节，需检查返回值，并在OP_WRITE就绪时继续写剩余内容（常配合buffer.hasRemaining()判断） - 每次处理完一个 key 后，务必调用
iterator.remove()，否则该 key 会在下一轮被重复处理
避免常见陷阱
实际编码中容易忽略几个关键点，导致逻辑卡死或 CPU 占满：
- 不要在
OP_READ就绪后，反复调用read()直到返回 0 ——这会陷入忙等；应读一次，处理当前 buffer 内容，然后等下一次就绪 - 注册
OP_WRITE要谨慎：它几乎总是就绪（除非发送缓冲区满），滥用会导致空转；一般只在 write 返回值小于 buffer 剩余长度时才临时注册，写完立刻取消 - Buffer 使用前要
flip()（读模式），用完要clear()或compact()，否则数据错乱或写不进 - 异常处理不能只 catch Exception：比如连接中断会触发
IOException，需要关闭对应 channel 和 key，并从 selector 中注销
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
