Java NIO中，对端主动close()触发OP_READ事件且read()返回-1，表示优雅关闭；物理断开则无任何Selector事件，需依赖心跳或写异常（如Broken pipe）探测。
对端物理断开（如拔网线、设备掉电）和主动调用 close()，在 Java NIO 的 Selector 机制中会触发**完全不同的底层信号路径**，服务端感知方式也截然不同——这不是“有没有事件”，而是“事件类型、读取结果、异常表现”的系统性差异。
正常 close()：OP_READ 触发 + read() 返回 -1
当客户端调用 Socket.close() 或 Channel.close() 时，TCP 层会发送 FIN 包，服务端内核收到后将该连接标记为“半关闭”。下一次 Selector 轮询检测到该 Channel 可读时，会触发 OP_READ 事件。
此时调用 channel.read(buffer)：
- 返回值为 -1 —— 这是 JDK 明确定义的 EOF 信号，表示对端已优雅关闭连接；
- 不会抛出
IOException； - 可安全执行清理逻辑：取消
SelectionKey、释放缓冲区、触发fireChannelInactive()等。
物理断开（掉电/断网）：无 FIN，仅靠超时或异常暴露
设备突然掉电、网线被拔、防火墙静默丢包等情况，不会发出 FIN 或 RST。服务端内核无法得知连接异常，TCP 连接仍处于 ESTABLISHED 状态，Selector 也不会主动触发任何事件。
因此：
- 不会产生 OP_READ / OP_WRITE / OP_CONNECT 事件 —— Selector 完全“沉默”；
- 后续
read()调用可能长期阻塞（若通道设为阻塞）或立即返回 0（非阻塞模式下，表示暂无数据，但连接仍“活着”）； - 真正暴露问题往往发生在写操作时：首次尝试
write()后，内核发现对端不可达，后续 write 可能抛IOException("Broken pipe")或Connection reset by peer； - 更常见的是，服务端长时间收不到心跳，只能依赖业务层保活机制（如 Netty 的
IdleStateHandler）触发超时判定。
关键变量信号对比表
核心区别不在 Selector 本身，而在 read()/write() 的返回值与异常类型：
- read() == -1 → 对端主动关闭（FIN 已收），可立即清理；
- read() == 0 → 非阻塞模式下“暂无数据”，不表示断连，需结合其他机制判断；
- write() 抛 IOException（含 Broken pipe、Connection reset） → 往往是物理断连后首次写入失败的典型信号；
- Selector.select() 长期返回 0，且无任何 key 就绪 → 不能说明连接健康，只说明当前无 I/O 事件，需靠心跳或 TCP keepalive 探测。
增强感知的实用建议
仅靠原生 NIO 的事件机制无法可靠区分物理断开，必须叠加防御性策略：
- 启用 TCP 底层保活：
channel.configureBlocking(false); channel.socket().setKeepAlive(true);（注意：OS 默认间隔长，见效慢）； - 应用层心跳必选：固定周期收发空消息或业务 ping/pong，并设置超时阈值（如 30 秒无响应即断连）；
- Netty 用户优先使用
IdleStateHandler，它基于 EventLoop 时间轮精准检测读/写空闲，比轮询更高效； - 避免仅依赖
isReadable()判断连接状态 —— 它只说明“可以尝试读”，不保证“能读到有效数据”或“连接还活着”。
