ClosedSelectorException 是选择器关闭后非法操作触发的运行时异常，非状态判定工具；应通过 isOpen() 主动检查、及时置空引用、避免异常控制流程，并确保线程安全关闭。
closedselectorexception 是 java nio 中选择器（selector）被显式关闭后，仍尝试对其执行操作（如 select()、register()、keys() 等）时抛出的运行时异常。它本身**不是用于主动判定生命周期状态的工具**，而是非法操作触发的**事后信号**。真正可靠的判定方式是**在操作前主动检查选择器是否已关闭**，而非依赖异常捕获来“判断”。
用 isOpen() 主动检查状态，避免触发 ClosedSelectorException
每个 Selector 实例都提供 isOpen() 方法，返回 boolean 值，准确反映其当前是否处于可操作状态：
- 返回
true：选择器未关闭，可安全调用select()、register()、selectedKeys()等 - 返回
false：选择器已关闭（调用过close()），任何操作都将抛出ClosedSelectorException
推荐在关键操作前统一校验：
if (selector.isOpen()) {
int readyChannels = selector.selectNow(); // 或 select(), select(long)
// 处理就绪通道...
} else {
// 选择器已关闭，跳过或清理资源
}
关闭选择器后立即置空引用并避免后续访问
调用 selector.close() 后，应尽快解除所有对该实例的强引用，防止误用：
- 将 selector 变量设为
null（尤其在线程局部或成员变量场景） - 若 selector 被多个组件共享，通过状态标志（如
volatile boolean isShutdown）协同控制访问权限 - 在线程池或事件循环中，确保关闭逻辑与事件分发线程同步，避免竞态下“刚关完就被另一个线程读取”
不依赖 try-catch ClosedSelectorException 做流程控制
虽然可以捕获该异常，但将其用于常规状态判断属于反模式：
- 异常创建开销大，频繁抛/捕影响性能
- 掩盖真实设计缺陷：本应在操作前规避，而非靠错误兜底
- 无法区分“正常关闭”和“意外关闭”（如未捕获的异常导致提前 close）
仅在极少数兜底场景使用（例如：不确定第三方库是否已关闭 selector，且无法修改其行为时）：
try {
selector.select();
} catch (ClosedSelectorException e) {
// 记录 warn 日志，清理关联资源，退出当前处理逻辑
logger.warn("Selector already closed, stopping selection loop");
return;
}
结合 Executor 和生命周期管理确保线程安全
选择器通常绑定单一线程（如 NIO 事件循环）。需确保关闭动作与使用线程串行化：
- 使用
Executor.execute()将close()提交到 selector 所属线程执行，避免跨线程调用 - 关闭前调用
selector.wakeup()中断阻塞的select()，使其尽快返回并进入关闭流程 - 关闭后等待线程终止（如
shutdown()+awaitTermination()），再释放 selector 引用
