setSoTimeout()仅对BIO生效，NIO中无效；BIO中它控制recv()阻塞读超时，抛SocketTimeoutException；NIO需用Selector.select(timeout)配合应用层逻辑实现读超时判定。
Java中setSoTimeout()只对BIO（阻塞式IO）生效，对NIO非阻塞模式完全无效——这不是配置遗漏或用法错误，而是由底层通信模型决定的硬性边界。
BIO中setSoTimeout控制的是“读等待”时长
在传统BIO场景下（如ServerSocket.accept()或Socket.getInputStream().read()），调用setSoTimeout(5000)后：
- 线程会在无数据可读时最多阻塞5秒，超时抛出
SocketTimeoutException，但连接仍保持活跃 - 它不作用于
connect()或write()，仅约束阻塞读操作 - 底层实际触发的是带超时参数的
recv()系统调用，内核代为等待数据入缓冲区 - 若设为0，表示永不超时（阻塞到底）；负值会抛出
IllegalArgumentException
NIO中setSoTimeout被忽略，无实际效果
NIO要求Channel必须处于非阻塞模式（configureBlocking(false)），此时：
-
setSoTimeout()调用不会报错，但也不起任何作用 -
read()方法立刻返回：有数据则读取、无数据返回0、连接关闭返回-1，绝不会阻塞或抛SocketTimeoutException - 真正的超时控制权交由
Selector.select(timeout)承担，它限制的是“事件就绪检查”的等待时间，而非数据读取本身
两种超时机制的本质差异
关键不在“有没有超时”，而在于“谁在等、等什么”：
立即学习“Java免费学习笔记（深入）”；
- BIO的
SO_TIMEOUT：应用层委托内核等数据到达缓冲区，等的是“数据是否已就绪” - NIO的
select(timeout)：应用层主动轮询多个Channel，等的是“是否有OP_READ等事件通知产生” - 前者适合单连接单线程简单服务；后者是高并发场景下自主调度与超时响应的基础
读超时逻辑需由NIO应用层自行实现
因为NIO读操作天然不阻塞，所谓“读超时”必须结合业务上下文判断：
- 例如：某Channel注册了OP_READ，
select(3000)返回0 → 可认为该连接3秒内无新数据，触发心跳检测或空闲断连 - 再如：一次
read()返回0，不代表结束，需配合上次读取时间戳判断是否超过业务定义的“读空闲超时” - 不能依赖异常中断流程，而要基于事件循环+时间戳+状态机做综合判定
