Java字节流与字符流不直接抛InterruptedException，但阻塞读取时可能抛InterruptedIOException；应显式捕获并恢复中断状态，或主动检查Thread.interrupted()以提升响应性。
Java 中字节流与字符流本身不直接抛出 InterruptedException，但读取过程可能被线程中断，进而引发 InterruptedIOException（IOException 的子类）——这是处理“读取中断”的关键入口。
字节流中识别和响应中断
字节流如 FileInputStream、SocketInputStream 在阻塞读取时，若当前线程被中断，底层可能抛出 InterruptedIOException。这不是标准强制行为（取决于具体实现和JDK版本），但在传统IO或某些网络库中仍常见。
- 用
try-catch(InterruptedIOException e)显式捕获，不要只 catchIOException - 捕获后应立即调用
Thread.currentThread().interrupt()恢复中断状态，避免“吞掉”信号 - 不建议在 catch 块中静默忽略或仅打印日志；需结合业务决定是否终止读取、释放资源或通知上层
字符流中的中断处理逻辑相同
字符流如 InputStreamReader、FileReader 底层仍依赖字节流，其中断表现与上层字节源一致。例如：
- 用
InputStreamReader包装一个被中断的SocketInputStream，read() 调用可能抛InterruptedIOException - 即使使用
BufferedReader，其readLine()本质也是委托给底层Reader，中断传播路径不变 - 注意：字符流不会因编码问题触发中断；乱码是
UnsupportedEncodingException或字节截断导致，与中断无关
更可靠的做法：主动检查中断状态
依赖异常被动响应不够健壮。推荐在循环读取中主动判断线程是否已中断：
立即学习“Java免费学习笔记（深入）”；
- 每次 read 前加
if (Thread.interrupted()) { break; }或抛InterruptedException - 对长时间运行的 IO 任务（如大文件分块读取），在每次批次处理后检查中断，提升响应性
- 配合
Future.cancel(true)使用时，确保任务内 IO 操作能及时感知并退出，避免资源滞留
避免中断被掩盖的常见错误
以下写法会丢失中断意图，应避免：
- 只 catch
IOException却未处理其子类InterruptedIOException - 捕获
InterruptedIOException后未调用Thread.currentThread().interrupt() - 在 finally 块中关闭流时，再次发生
IOException掩盖了原始的中断异常 - 使用 try-with-resources 时，若构造阶段就中断（如 new FileInputStream 时阻塞在打开文件），异常类型可能为
InterruptedIOException，需在外层捕获
