Java NIO中“远程主机强迫关闭连接”本质是TCP连接被对端主动断开，服务端需显式检测read()返回-1或捕获IOException来清理资源，优先以read()==-1为断连信号，配合心跳超时、半关闭处理等增强健壮性。
Java NIO 中遇到“远程主机强迫关闭了一个现有的连接”异常，本质是底层 TCP 连接已被对端（客户端）主动断开（如调用 close()、shutdownOutput()，或进程崩溃、网络中断），而服务端仍在尝试读写该 Channel。NIO 不会自动屏蔽这种底层中断，必须由代码显式识别并清理资源。
检测连接是否已断开
NIO 的 SocketChannel.read() 在对端关闭连接后会立即返回 -1，这是最可靠、最轻量的断连信号。不能依赖异常触发才处理——异常往往发生在重复读写之后，且可能掩盖真实状态。
-
永远先检查 read() 返回值：只要
read(buffer)返回 -1，说明对方已正常关闭连接（FIN 包到达），应立即取消 SelectionKey、关闭 Channel、释放 ByteBuffer - 不要在 read() 为 -1 后继续 write()：此时 Channel 已不可写，强行 write 可能触发 IOException 或阻塞
- 区分 -1 和 0：返回 0 表示本次无数据可读（非断连），需等待下一次就绪；返回 -1 才代表连接终结
捕获并正确响应 IOException
尽管应优先靠 read()==-1 判断，但某些场景（如 write 时对方突然断网、RST 包到达）仍会抛出 IOException，常见如 java.io.IOException: Broken pipe 或 Connection reset by peer。这些都属于可预期的网络异常，需捕获而非打印堆栈后终止线程。
- 在 OP_READ / OP_WRITE 处理块中统一 try-catch：不建议只 catch read 操作，write 和 flush 同样可能失败
- 捕获后执行标准清理流程：取消 key、关闭 channel、移除对应业务上下文（如 session map 中的条目）
- 避免在异常处理中再调用 channel.close()：因为 channel 可能已失效，重复 close 可能抛新异常；推荐用 try-with-resources 或显式判空关闭
避免因 shutdownOutput 引发误判
客户端调用 socket.shutdownOutput()（或 NIO 中 channel.shutdownOutput()）仅关闭写方向，TCP 连接仍可读。但很多服务端代码未区分 FIN 和 RST，误将 shutdownOutput 当作完全断连，在后续 read 时发现返回 -1 就清理资源，却忽略了自己还没回传响应。
立即学习“Java免费学习笔记（深入）”；
- 服务端收到 read()==-1 后，若还有待发送数据，应先 write 完再关闭：比如上传协议中，客户端传完文件后 shutdownOutput，服务端需返回处理结果后再 close
- 不要在 read==-1 后立刻 write：需确认当前 buffer 是否有未 flush 的响应数据，否则 write 可能失败
- 使用半关闭语义时，明确约定通信协议：例如规定“客户端 shutdownOutput 后，服务端必须在 X 秒内完成响应并关闭”
增强健壮性的配套措施
单靠异常处理不够，需结合心跳、超时和状态管理构建容错能力。
- 为每个活跃 Channel 绑定最后通信时间戳：在每次 read/write 后更新；Selector 循环中定期扫描，超时（如 30 秒无 activity）则主动 cancel key 并 close
- 禁用 Nagle 算法（TCP_NODELAY）：减少小包延迟，让 FIN/RST 更快被感知，尤其对高频短交互场景有效
- 不在 Selector 线程中做耗时操作：如文件写入、数据库查询。应将任务提交到业务线程池，避免阻塞整个事件循环导致断连堆积
