ClosedChannelException 表示通道生命周期已终结，因显式关闭或对端断连导致 channel 失效，调用 write() 等 I/O 方法时立即抛出；需在写前校验 isOpen() && isConnected()，并单独捕获处理。
为什么调用 write() 时突然抛出 ClosedChannelException
因为底层 SocketChannel 或 FileChannel 已被显式关闭（close()），或对端断连后本地通道自动失效，此时再调用 write()、read()、flush() 等 I/O 方法就会立即失败。
常见错误现象：程序运行一段时间后偶发崩溃，堆栈里固定出现 java.nio.channels.ClosedChannelException，但没明显主动关通道的代码；或者在连接池中复用 channel 后忘记检查状态，直接写数据。
- 不是所有 close() 都是显式的——
try-with-resources自动关闭、Netty 的ctx.close()、HTTP 客户端连接超时回收，都可能导致 channel 悄悄失效 -
isConnected()和isOpen()必须一起查：isOpen()为true不代表还能读写，isConnected()为true也不代表对端还活着 - NIO 中 channel 是线程不安全的，多线程并发调用
close()+write()极易触发该异常，且难以复现
ClosedChannelException 和 IOException 的区别在哪
它继承自 IOException，但语义更明确：问题不在系统资源、权限或网络抖动，而是「通道生命周期已终结」。JVM 不会尝试重试或恢复，必须由业务层决定是重建连接、丢弃请求，还是返回错误响应。
性能影响很小——异常本身开销低，但频繁抛异常说明设计有问题：比如心跳缺失导致连接被服务端静默关闭，客户端却还在往旧 channel 写数据。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 别用
catch (IOException e)笼统处理——会掩盖真实的连接中断、超时等其他问题 - 应单独捕获
ClosedChannelException，并记录 warn 日志，带上 channel 的 key 或 remote address 方便排查 - 某些框架（如 Netty）会把该异常包装成
ChannelException或WriteTimeoutException，要看实际堆栈最内层的 cause
如何安全地向可能已关闭的 channel 发送数据
核心原则：写之前做轻量级状态校验，而不是靠异常兜底。NIO 的非阻塞特性决定了「先检查再操作」比「操作失败再重试」更合理。
- 检查顺序必须是：
channel.isOpen() && channel.isConnected()—— 少一个条件都可能漏判 - 对于
SocketChannel，可加一层socket.isClosed() || !socket.isConnected()辅助判断（但注意 socket 方法是同步的，别在高并发写路径里调用） - 如果使用连接池（如 Apache HttpClient 的
PoolingHttpClientConnectionManager），确保获取连接后调用isStale()或发送探测包，而非直接 write - 示例片段：
if (channel.isOpen() && channel.isConnected()) { channel.write(buf); } else { // 清理引用，触发重连逻辑 }
Netty 场景下为什么 ctx.writeAndFlush() 还会触发 ClosedChannelException
因为 Netty 的 ChannelHandlerContext 是事件驱动的，writeAndFlush() 只是把任务提交到 pipeline，真正落到底层 channel 是异步的。如果在这期间 channel 被 close()（比如 idle timeout 触发、用户手动断连），task 执行时就会抛该异常。
这不是 bug，是 NIO 异步模型的必然结果。Netty 默认会把这类异常传给 exceptionCaught()，但如果你没重写这个方法，异常就吞掉了，表现为数据静默丢失。
- 务必在
ChannelInboundHandler中实现exceptionCaught()，对ClosedChannelException做空处理或打日志（避免刷屏） - 不要在
channelInactive()之后还往ctx写数据——这两个回调之间没有严格时序保证，需加 volatile 标记或 AtomicBoolean 控制 - 如果用
DefaultChannelPromise监听写结果，其isSuccess()为false且cause()是ClosedChannelException，说明写入被丢弃
ClosedChannelException 可能是表象，背后是 channel 被重复关闭三次，或某个 handler 忘了移除自身。 
