socketchannel.configureblocking(false) 主要改变java层io语义：read()立即返回0/-1/正值，write()可能部分写出需循环处理，connect()变为异步需finishconnect()确认，且必须配合selector使用。
调用 SocketChannel.configureBlocking(false) 并不会直接修改操作系统底层 socket 的 blocking/non-blocking 状态，而是让 Java NIO 库在用户态绕过阻塞系统调用，并借助操作系统提供的非阻塞 I/O 机制（如 Linux 的 epoll、Windows 的 IOCP）来实现高效轮询与事件通知。
它不直接执行 fcntl(fd, F_SETFL, O_NONBLOCK)
表面上看，configureBlocking(false) 和系统调用 fcntl(fd, F_SETFL, O_NONBLOCK) 效果相似——都让 socket 进入非阻塞模式。但 Java 在底层做了封装：JDK 通常会在创建 SocketChannel 时就将对应文件描述符设为非阻塞（例如在 UnixDomainSocketChannelImpl 或 SocketChannelImpl 初始化阶段），后续的 configureBlocking(false) 更多是状态同步和语义校验。也就是说，它主要改变的是 Java 层对这个 channel 的使用契约，而非实时“翻转”内核 socket 标志位。
真正起作用的是 Java 的 Selector + 系统事件机制
当 channel 设为非阻塞后，Java 不再调用 read() 或 write() 等可能阻塞的系统调用，而是：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 在
read()时，若内核接收缓冲区为空，立即返回 0 或抛出IOException（如java.io.IOException: Connection reset），而不是挂起线程； - 所有 I/O 操作都配合
Selector使用：JVM 将该 channel 注册到Selector，由底层epoll_wait（Linux）或select/WSAPoll（Windows）监听就绪事件； - 真正读写仍通过
read(ByteBuffer)/write(ByteBuffer)发起，但 JVM 内部会用recv/send等非阻塞系统调用，并检查EAGAIN/EWOULDBLOCK错误码来决定是否继续等待。
操作系统 socket 行为变化的关键点
虽然 Java 层不每次都调用 fcntl，但最终生效的仍是操作系统对 fd 的非阻塞设置。关键影响包括：
-
系统调用不再休眠：如
recv()在无数据时立刻返回 -1 +EAGAIN，而不是让线程进入 TASK_INTERRUPTIBLE 状态； -
TCP 连接建立行为不变：
connect()仍会返回EINPROGRESS，需靠OP_CONNECT事件判断完成； - 发送缓冲区满时表现不同：非阻塞 write 可能只写出部分数据（partial write），必须检查返回值并手动重试；
-
关闭流程更复杂：不能依赖 close() 阻塞等待 FIN-ACK，需结合
OP_READ判断对方是否关闭连接（read 返回 -1）。
注意：configureBlocking(true) 有局限性
一旦 channel 被注册到 Selector，就不能再设回阻塞模式（会抛 IllegalBlockingModeException）。这是因为 Selector 内部依赖底层非阻塞 fd，强行切换会导致事件循环失效。这也说明：Java 的非阻塞模式是面向整个 NIO 生态设计的，不是孤立的 socket 属性开关。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
