如何在Netty客户端实现断线自动重连

channelInactive 由于底层资源没有完全释放，不能立即重新连接，需要等待 closeFuture 完成或延迟后 connect；推荐用 HashedWheelTimer 实现指数退出重连，确保 Bootstrap 配置一致，分类处理异常，心跳保存。

channelInactive 触发后为什么不能立即重连？

Netty 的channelInactive事件只表示 Channel 但此时底层资源已断开(如 NIO 的SelectionKey）可能还没有完全释放，直接调用bootstrap.connect()会抛IllegalStateException: channel not active或者沉默失败。

• 必须等channel.closeFuture().isDone() == true然后启动新的连接，否则新的连接请求将被丢弃
• 更安全的方法是延迟一小段时间(比如 100ms)，或监控channel.closeFuture()然后触发重连逻辑
• 别在channelInactive在回调中同步执行 connect —— 这是新手最常踩的坑

用 HashedWheelTimer 实现可控重连间隔

不用Thread.sleep或ScheduledExecutorService，Netty 自带的HashedWheelTimer重量轻，线程安全，可避免定时任务堆积(如连续断连时未取消旧任务)。

• 全局初始化HashedWheelTimer，可以重用，不要每次重连都重用。 new 一个
• 重连前先 cancel 掉上一次的Timeout对象，防止重复触发
• 推荐初始延迟 1s，后续指数退出(如 1s → 2s → 4s → 8s，上限 30s)，避免雪崩重连

timer.newTimeout(timeout -> { if (channel == null || !channel.isActive()) { bootstrap.connect(host, port).addListener(future -> { if (!future.isSuccess()) { scheduleReconnect(); // 下一次递归调度 } }); } }, delay, TimeUnit.SECONDS);

重连时 Bootstrap 配置应与初连一致

许多重连失败是由于修改后的复用Bootstrap实例：比如 handler 重复添加，option甚至被覆盖group被设为null。

• 不要在initChannel里动态 addLast 新 handler；重连将再次执行，导致重连 pipeline 重复
• 所有option（如SO_KEEPALIVE、TCP_NODELAY）和attr必须首次创建Bootstrap一次性配好
• 假如使用了自定义ChannelHandler，确保它多次支持 init(例如，状态清零，不持有已关闭 channel 引用）

如何判断是否应该继续重连

并非所有断连都要无限重试。比如服务端完全下线，DNS 分析失败，本地网络无法到达，硬重连只会浪费资源。

• 检查异常类型：java.net.UnknownHostException、java.net.ConnectException: Connection refused可立即终止
• 记录连续失败次数，超过阈值(如 5 二)重连暂停或降级到备用地址
• 增加开关控制：通过channel.attr(ATTR_RECONNECT_ENABLED)动态启停方便运维干预

真正的麻烦是“假连接”——TCP 握手成功，但业务层没有回应，这取决于心跳 + 读超时（ReadTimeoutHandler）来识别，光靠channelInactive是不够的。