NIO客户端自动重连需控制节奏、隔离异常、避免泄漏，依托Selector事件驱动，动态管理延迟变量；触发重连须捕获connect超时、read返回-1、IO异常三类状态；延迟变量应绑定连接状态对象并指数退避；重连动作须由Selector线程安全调度；需结合应用层心跳检测防“假在线”。
在 NIO 客户端中实现自动重连，关键不是“立刻重试”，而是**控制重试节奏、隔离异常影响、避免资源泄漏**。非阻塞模式下不能靠阻塞等待（如 Thread.sleep），必须依托 Selector 的事件驱动机制，把重连动作纳入轮询调度体系——延迟变量（如重连间隔）需动态管理，而非写死。
重连触发点必须明确捕获三类异常场景
仅靠连接失败日志或 try-catch 外层抛出是不够的。真正可靠的触发依据来自 Selector 轮询过程中的可观察状态：
-
connect 操作未完成且超时：
socketChannel.finishConnect()返回false，且已过预设连接超时时间（需自行记录发起连接的时间戳） - read 操作返回 -1：表示对端正常关闭连接，此时应主动清理 key 并触发重连
-
OP_READ 或 OP_WRITE 出现 IOException（如 Connection reset、Broken pipe）：Selector 会将该 key 的 interestOps 置为 0，需在
selectionKey.isReadable()或selectionKey.isWritable()判断后，捕获其key.channel().isOpen()为 false 或读写抛出异常
延迟变量要绑定到连接状态对象，不可全局共享
多个客户端实例或同一客户端多次断连时，若共用一个 reconnectDelayMs 变量，会导致退避策略失效（比如第二次断连直接用上次的 30 秒，而非从 1 秒开始）。正确做法是：
- 为每次连接维护独立的状态对象（例如
ConnectionState类），内含currentDelayMs、failCount、lastAttemptTime - 首次失败设
currentDelayMs = 1000；每次失败后按指数退避更新：currentDelayMs = Math.min(currentDelayMs * 2, 30_000) - 成功连接后重置
failCount = 0，currentDelayMs = 1000
重连动作必须由 Selector 线程安全调度
不能在 IO 异常处理中直接调用 socketChannel.connect(...) —— 此时 channel 可能尚未注销，或 selector 正在 select 中，导致 CancelledKeyException 或线程不安全。正确流程是：
- 捕获异常后，调用
selectionKey.cancel()并selectionKey.channel().close() - 使用
selector.wakeup()唤醒阻塞中的select() - 在下一轮
select()开始前，通过selector.provider().openSelector()新建 channel（或复用已关闭 channel 的 socket 地址），并注册OP_CONNECT - 若需精确控制延迟（如 2 秒后重连），可在唤醒后，用
System.nanoTime()计算下次允许连接的时间点，在循环中跳过重连逻辑直到到达该时刻
心跳检测与重连协同才能避免“假在线”
仅靠 TCP 连接存活不等于业务可用。真实场景中需叠加应用层心跳：
- 建立连接后，启动一个独立的定时任务（可用
ScheduledThreadPoolExecutor），每 15 秒发一次心跳包 - 收到心跳响应则刷新
lastHeartbeatAt；连续 3 次未响应（即 45 秒无有效响应），视作链路异常，主动断开并进入重连流程 - 该机制与上述 Selector 重连逻辑正交：心跳失败走主动断开 → cancel key → 触发重连；网络闪断则由 read 异常触发重连 —— 两者最终都归入同一重连状态机
