InterruptedIOException 在现代 Socket 编程中极少由标准 API 抛出，真实场景多抛 SocketException 或 IOException；应改用 NIO、主动检查中断或 Future.cancel 等可控方式处理中断。
InterruptedIOException 并不适用于现代套接字读写中断
该异常在语义上表示“IO操作因线程中断而失败”，但它在真实网络编程中几乎不被标准 Socket API 抛出。Java 的 SocketInputStream 和 SocketOutputStream 在阻塞模式下被中断时，通常不会抛 InterruptedIOException，而是直接抛 SocketException（如 SocketException: Connection reset）或更常见的 IOException，甚至某些情况下静默返回 -1 或 0。它主要存在于早期 JDK 的部分自定义流实现中，而非 java.net 核心类库。
真正起作用的是线程中断 + 底层 socket 关闭联动
当对正在执行 socket.getInputStream().read() 的线程调用 interrupt() 时，JVM 的行为取决于底层操作系统和 socket 状态：
- 若 socket 处于阻塞等待数据状态，Linux/BSD 上通常触发
EINTR，但 Java 层会将其包装为普通IOException，而非InterruptedIOException - 若 socket 已被另一线程关闭（
socket.close()），则后续 read 会立即抛SocketException: Socket is closed - 若使用
setSoTimeout()，超时后抛的是SocketTimeoutException，它继承自IOException，但与中断无关
现代替代方案更明确、更可控
依赖 InterruptedIOException 判断中断既不可靠也不推荐。应转向以下实践：
- 使用
java.nio.channels.SocketChannel配合Selector：中断会触发ClosedByInterruptException，类型清晰，且可配合configureBlocking(false)实现非阻塞轮询 - 主动检查中断状态：在循环读取逻辑中定期调用
Thread.currentThread().isInterrupted()，避免陷入无法响应的阻塞 - 配合
Future.cancel(true)终止异步任务：ExecutorService 提交的任务被取消时，会向工作线程发起中断，此时你应在 IO 循环中响应并退出
静默吞掉中断是最大风险点
即使捕获到 InterruptedIOException（比如来自某第三方通信库），也绝不能只打日志就结束：
- 必须调用
Thread.currentThread().interrupt()恢复中断标志，否则上层调度逻辑将丢失信号 - 需确保资源（如
InputStream、Socket）被及时关闭，防止句柄泄漏 - 不应假设该异常一定代表“用户请求取消”——它也可能是框架内部误中断，需结合业务上下文判断是否终止流程
