SO_TIMEOUT仅适用于阻塞I/O的读操作，超时后抛出SocketTimeoutException但连接保持；NIO中无SO_TIMEOUT，超时由Selector.select(timeout)控制就绪检查，读操作本身非阻塞，需应用层自主实现读超时逻辑。
SO_TIMEOUT 是 Socket 层面对读操作（recv）设置的超时控制，只作用于阻塞式 I/O；而 NIO 中没有 SO_TIMEOUT 这个概念，它的超时由 Selector 的 select(timeout) 控制，两者底层机制、作用对象和触发条件完全不同。
SO_TIMEOUT 只影响阻塞 socket 的 read/recv 调用
当 Socket 处于阻塞模式（默认行为），且调用了 setSoTimeout(5000)，那么后续每次 InputStream.read() 或 Socket.getInputStream().read() 在无数据可读时，会最多等待 5 秒——超时后抛出 SocketTimeoutException，但连接本身保持打开状态，可继续读或写。
关键点：
- 它不控制 connect() 或 send() 的超时，仅对阻塞读生效
- 内核实际执行的是带超时的
recv()系统调用，底层可能通过poll()或select()实现等待 - 超时后线程恢复运行，程序需显式捕获异常并决定是否重试或关闭连接
Selector 的 select(timeout) 控制的是“就绪检查”的等待时间
NIO 中 Channel 必须设为非阻塞模式，不能用 SO_TIMEOUT。真正实现超时逻辑的是 Selector 的 select(long timeout) 方法：它让线程在“有没有 Channel 就绪”这件事上最多等 timeout 毫秒。
例如：
-
selector.select(5000)表示：最多等 5 秒，看是否有 OP_READ / OP_WRITE / OP_CONNECT 等事件发生 - 一旦有任意一个注册的 Channel 就绪，方法立即返回，
selectedKeys()返回待处理集合 - 若超时未就绪，方法返回 0，程序可据此做心跳、清理空闲连接等操作
根本差异在于“谁在等”和“等什么”
SO_TIMEOUT 是应用层告诉内核：“请替我等数据到来，最多等 X 毫秒”，等的是数据是否已进入内核缓冲区；而 Selector.select(timeout) 是应用层自己轮询：“我来查一遍哪些 Channel 已就绪，最多花 X 毫秒查完”，等的是事件通知是否产生。
这也决定了它们的适用场景：
- 阻塞 IO + SO_TIMEOUT：适合连接数少、逻辑简单、每个连接独占线程的模型
- NIO + Selector 超时：适合单线程/少量线程管理成千上万连接，需自主调度与超时响应的高并发服务
注意：NIO 中读操作本身不会超时，必须配合业务逻辑判断
非阻塞 Channel 的 read(buffer) 永远不会阻塞：没数据就立刻返回 0 或 -1（-1 表示 EOF），不会抛异常。所以真正的“读超时”要靠上层逻辑实现，比如：
- 记录某 Channel 上次读到数据的时间戳
- 在每次
select()返回后，遍历 selectedKeys，检查各 Channel 是否空闲超过阈值 - 手动关闭长时间无活动的连接
这正是 NIO 把超时控制权交还给应用的设计哲学——更灵活，也更需要开发者主动管理。
