SocketChannel.configureBlocking(false)将其切换为非阻塞模式，使read()、write()、connect()立即返回并交由调用方判断状态：read()返回正值（读取字节数）、0（无数据）、-1（对端关闭）；write()可能只写部分字节，需循环处理；connect()异步启动，需finishConnect()确认结果；必须配合Selector使用以避免忙等。
SocketChannel.configureBlocking(false) 把通道从默认的阻塞模式切换为非阻塞模式，它不改变方法签名，但彻底改变了 read()、write()、connect() 等 IO 方法的行为语义：它们不再等待操作完成，而是立即返回，并把“是否就绪”和“完成多少”的判断权交还给调用方。
read()：不再挂起，返回值即状态
阻塞模式下，read(ByteBuffer) 会一直等有数据可读才返回；非阻塞后，它立刻返回：
- 返回正值：表示成功读取的字节数（可能远小于 buffer 容量）
- 返回 0：没有数据可读，也不表示连接关闭或出错
- 返回 -1：对端已正常关闭连接（EOF）
- 不会抛出
IOException表示“暂时没数据”，仅在真实异常（如连接重置）时才抛
write()：不保证写完，需循环处理
阻塞模式下，write(ByteBuffer) 尽力把 buffer 中剩余字节全部发出才返回；非阻塞后：
- 只尝试写出当前内核发送缓冲区能容纳的部分，然后立即返回已写出字节数
- 返回值可能小于 buffer 中待写入的字节数（
buffer.remaining()） - 若返回 0，说明发送缓冲区已满，但连接仍有效，需等
OP_WRITE就绪后再试 - 必须手动检查返回值、更新 buffer 位置（
buffer.compact()或flip()），并在合适时机重试
connect()：变成异步握手启动器
非阻塞下 connect(SocketAddress) 不再等待 TCP 三次握手完成：
- 调用后立即返回
true表示连接已建立（极少见，本地回环可能） - 返回
false表示连接仍在进行中，此时需注册OP_CONNECT到 Selector - 后续必须调用
finishConnect()来确认连接结果（成功/失败/仍在进行） - 不能在未确认前调用
read()或write()
配套要求：必须与 Selector 协同使用才真正高效
单独设为非阻塞而不用 Selector，容易陷入忙等（busy-waiting）：
- 没有数据时反复调用
read()浪费 CPU - 发送缓冲区满时反复调用
write()无效且低效 - 正确做法是将 SocketChannel 注册到 Selector，关注
OP_READ、OP_WRITE、OP_CONNECT事件，在对应就绪时才调用相应 IO 方法 - Selector 的
select()是阻塞的，但它管理的是成百上千个通道，避免了线程数量爆炸
