asynchronouscloseexception 是非受检异常，继承自 closedchannelexception（而非 ioexception），表示通道被其他线程异步关闭，属合法竞态，应通过状态标记、非阻塞模式或统一关闭管理预防，而非强制捕获处理。
AsynchronousCloseException 是 Java 中一个非受检异常（unchecked exception），继承自 java.io.IOException，但它不强制要求 try-catch 或 throws 声明。所以标题中“受检异常”的说法是错误的——它不是受检异常，无法也不应按受检异常方式处理。
为什么 AsynchronousCloseException 不是受检异常
Java 的受检异常（checked exception）必须显式处理（捕获或向上抛出），比如 IOException、SQLException；而 AsynchronousCloseException 虽然继承自 IOException，但其父类 IOException 是受检的，它本身却被定义为 运行时异常的语义（构造函数未改变检查性质，且 JDK 源码中从未要求强制处理）。JVM 在通道（Channel）被其他线程主动关闭时抛出它，属于典型的“并发干扰”场景，设计上就偏向由程序逻辑规避，而非被动捕获。
- 查看 JDK 源码：它没有声明新的受检行为，只是普通继承
- 编译器不会报错：即使不 catch，代码也能通过编译
- 文档明确说明：Javadoc 写着 “Unchecked exception thrown when an I/O operation is interrupted by closing the underlying channel”
它通常在什么场景下发生
常见于 NIO 编程中，当一个线程正在执行阻塞或非阻塞 I/O 操作（如 channel.read(buffer)、selector.select()），而另一个线程调用了 channel.close() 或 selector.close() 时，正在操作的线程会立即收到该异常。
- 多线程共享同一个
SocketChannel或FileChannel，未加同步就关闭 - Netty 或自研 NIO 框架中，连接断开清理逻辑与读写任务竞争
- 使用
AsynchronousSocketChannel时，调用close()后仍有未完成的read()或write()回调执行
正确应对策略：预防优于捕获
由于它是并发导致的状态冲突信号，最佳实践是避免触发条件，而不是层层 try-catch。捕获它仅用于兜底日志或资源清理，不能当作正常流程分支。
- 对共享通道/选择器做关闭状态检查：关闭前设置 volatile 标志，I/O 循环中先检查再操作
- 使用
try-finally或try-with-resources确保单线程内资源生命周期清晰 - 在 Netty 等框架中，依赖
ChannelFuture监听关闭完成，而非直接调用channel.close() - 若必须捕获，只在顶层 I/O 循环中统一处理，并记录 warn 日志，避免吞掉异常掩盖问题
示例：安全关闭 Channel 的写法
不要这样：
❌ 错误：无防护地并发 close + readthread1: channel.read(buf);thread2: channel.close(); // → AsynchronousCloseException in thread1
推荐这样：
✅ 正确：协作式关闭用 AtomicBoolean 控制状态，读循环中主动退出：
- 声明
private final AtomicBoolean closed = new AtomicBoolean(false); - 关闭方法：
if (closed.compareAndSet(false, true)) channel.close(); - 读循环中：
while (!closed.get() && channel.read(buf) != -1) { ... }
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
