java nio通道中断是线程协作取消信号，恢复核心是安全退出、状态可续、资源不泄漏；需分类响应asynchronouscloseexception（立即终止）、interruptedioexception（恢复中断状态）、filelockinterruptionexception（清理并降级）；通过atomicboolean管控生命周期、selector驱动非阻塞i/o预防中断；断点外置持久化，新通道续传；资源清理与状态落盘分离，避免断点丢失。
Java NIO 中通道意外中断（如 AsynchronousCloseException、InterruptedIOException、FileLockInterruptionException）不是系统故障，而是线程协作取消的信号。恢复逻辑的核心不是“重连”或“重试”，而是**安全退出 + 状态可续 + 资源不泄漏**。
明确中断类型，分类响应
不同异常语义不同，不能统一 catch：
- AsynchronousCloseException：通道被其他线程主动关闭，当前 I/O 操作被强制中止。应视作“关闭通知”，立即终止读写循环，不做重试。
-
InterruptedIOException：线程被中断导致阻塞 I/O 中断（如
FileChannel.read()在阻塞模式下被 interrupt）。需恢复中断状态：Thread.currentThread().interrupt()，再决定是否退出任务。 -
FileLockInterruptionException：在
lock()或tryLock()等待锁时被中断。说明锁获取被取消，不应继续等待，应清理并返回或降级处理（如改用无锁策略）。
避免竞态，统一管控通道生命周期
多数“意外中断”源于多线程对同一通道的并发操作。关键不在捕获异常，而在预防：
- 用
AtomicBoolean closed = new AtomicBoolean()标记通道是否已关闭，所有 I/O 操作前先检查!closed.get()。 - 关闭操作由单一管理器执行（如连接池中的 close() 方法），其他线程仅通过回调、事件监听或轮询状态感知关闭，不直接调用
channel.close()。 - 使用
Selector配合非阻塞通道，用select()和就绪事件驱动 I/O，避免长时间阻塞调用，自然降低被中断风险。
保障状态可续，不依赖通道本身
通道不可恢复，但业务状态可以。例如大文件传输或日志解析：
- 维护外部断点（如已处理字节偏移量或行号），每次成功处理一段数据后，用原子方式（临时文件 + 原子替换）持久化断点。
- 恢复时，不尝试复用原通道，而是新建通道，从断点位置重新打开（
RandomAccessFile或FileChannel.open(..., READ)+position(offset)）。 - 对
transferTo()等分段操作，记录已传输总字节数，重启后跳过已传部分，继续循环调用。
资源清理与异常传播分离设计
不要把断点保存、状态落盘等关键逻辑绑在 try-with-resources 的 close() 中——异常可能发生在 close 前，导致断点丢失：
- 用
try-with-resources管理通道、缓冲区等 AutoCloseable 资源，确保物理资源释放。 - 将断点更新、日志提交等状态持久化逻辑放在业务处理的
finally块，或外层catch中独立执行。 - 若方法签名允许，对
InterruptedException直接throws；若必须吞（如Runnable.run()），则catch后必须interrupt()并考虑包装为RuntimeException向上透传。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
