做企业福利网站起名网络整合营销的特点有

引

netty既能开发socket服务端，也可开发客户端，实现连接的全双工通信。在客户端断线重启后，可自动重连服务端。

场景

本地代码既有socket客户端也有服务端，都是实现了同时收发功能。
前段时间发现本地的客户端，在服务端重启后不会自动重连，经debug后，发现起始重连的监听生效的，但是重连的connet方法没有执行成功。
最近又发现远程的客户端在连接本地服务端时，如果是远程客户端重启或连接关闭后重连时，本地收不到重连信号。前后两个场景对本地这套代码而言，起始都是同样的问题。

案例

socket长连接能够低延迟的监控到服务端和客户端状态，服务端、客户端在服务重启或网络异常时会断开连接，状态恢复后，由客户端主动发起重连（貌似也可以服务端主动重连客户端，方案上感觉是可行的，但感觉没啥意义）。
客户端在执行connet方法创建通道成功后，ChannelFuture可以通过添加监听器的方式，监听服务端的状态，连接断开后，在监听中可以实现重连实现。
上面提到了连接断开时，监听器生效了又重新执行重连方法，但是连接没有成功。
connet方法的执行对象是io.netty.bootstrap.Bootstrap，那问题就只能出在执行服务端启动或客户重连的这个共同对象bootstrap了。

bootstrap

bootstrap对象在声明时，可以添加多个handler，对象类型为io.netty.channel.ChannelHandler。经过反复对比，问题就出在了这一块儿。如消息的编码、解码器，异常处理器，消息接收器等等，这些handler大部分都是我们业务代码手动定义实现或重写的，handler被声明为了spring bean，内部依赖了其它bean。

在整个connet方法外面包一层try catch也不会抛出什么异常。这一点，我感觉netty内部的异常处理机制不是特别友好，有遇到好几次netty连接或者是收发消息异常，但是服务整体不报错，异常被netty内部吃掉了。

这里遇到的客户端断线无法自动重连或远程客户端断线后无法连接本地服务端，如果能从netty内部把这个异常抛出来，其实就很好定位了。

最后我想可能猜到已经猜到我遇到的问题在哪里了。我注入hadler的依赖，无法二次识别。
我习惯使用lombok的@RequiredArgsConstructor注解去自动注入依赖，handler所需要的依赖，通过此注解自动注入到了netty客户端或者是服务端的bean中，首次启动或重连时，可以注入成功。但第二次就不可重用了。替换成new的方式创建handler就是正确的，本地客户端自动重连和让远程客户端重连本地服务端都正常。