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 是不够的。
