背景 我编写的是netty客户端，需要向服务端根据时间节点推送数据。 过程 用了几个小时辛辛苦苦的把代码编写完毕，然后测试，服务端正常收到数据，嗯，心想，还行，没有什么太大的问题，于是就提交代码，上线部署到服务器。部署上去后，能正常的进行通信，没问题，我就做其他的事情去了。但是第二天同事给我说服务端收不到数据了，我心想，难道是连接端了，然后我立马在发送消息的地方加上发送日志，现在服务端说又行了，我想：“难道真的是连接断了，关键我也做了连接断开重连的操作了啊，怎么还会发送不成功呢？”，于是我查看代码，看不出所以然来，看着能正常通信我也就暂时放下去做其他的事情了。过了一会，写服务端的同事又来给我说收不到数据了，我打开了我部署的客户端服务，查看日志，发现日志正常，一直在推送，于是我就跟服务端的同事说，客户端都是正常的啊，日志发送正常，没有问题，是不是服务端出现问题了，然后去排查服务端的程序，一同排查下来没有问题，这时候我们都有点懵逼了，没遇到过这种情况啊。于是没办法了，加日志呗，多加点日志看看执行情况。通过日志发现客户端触发了channelInactive方法，接收到了服务端离线的事件，然后我们查看日志发现没有编码器的日志，到这里我想，怎么会呢，发送数据都成功了，怎么没有走编码器呢。然后开始排查代码，发送没有问题。然后就自己琢磨，既然客户端触发了channelInactive事件，连接应该是断开了，但是没有调重新连接的方法，难道是连接没有真正的断开嘛？于是在继续在通道判断方便加上日志，然后手动让服务端掉线，观察客户端日志，发现确实是这样。客户端和服务端之间的通道还是存在的，通道并没有真正的断开。既然发现了问题，就好解决了，于是我想到了两个解决方案

1、第一个就是在客户端触发channelInactive方法的时候手动关闭通道

2、第二个就是检查通道的活动状态 isActive方法判断当前通道是否是活动的，如果是就发送数据，如果不是就关闭当前通道重新建立连接。

这就是这次我遇到的一个坑，也不算是坑吧，自己想当然的判断了客户端和服务端的连接断开后通道就断开了，没有去判断当前通道的活动状态。

Netty触发了channelInactive但是连接还在的原因可能是在关闭或终止某个通道或会话时，底层的Socket没有立即关闭，而只是处于非活动状态。这可能是因为网络延迟、缓冲区数据未完全发送、或者其他原因。当底层的Socket关闭时，通道或会话的状态也会变为关闭状态。 因此，即使触发了channelInactive，实际上的连接可能仍然存在，只是被标记为非活动状态。在实际的网络编程中，非活动状态并不一定意味着连接已经完全断开。需要关注底层的Socket状态以获得准确的连接状态信息。

通过Socket类的isClosed()方法：该方法返回一个布尔值，表示Socket是否已经关闭。如果返回true，则表示Socket已经关闭；如果返回false，则表示Socket仍然打开。 通过OutputStream的write()方法：如果Socket已经关闭，则在使用OutputStream的write()方法时，会抛出IOException。因此，可以通过try-catch语句来捕获异常，从而判断Socket是否关闭。 通过InputStream的read()方法：如果Socket已经关闭，则在使用InputStream的read()方法时，会返回-1。因此，可以通过检查返回值是否为-1来判断Socket是否关闭。 通过设置连接超时时间：通过在Socket上设置连接超时时间，如果在超时时间内没有收到任何数据，则可以认为Socket已经关闭。 需要注意的是，这些方法只是判断Socket是否关闭的常用方法，实际情况可能会因操作系统、网络环境等因素而有所不同。因此，在实际应用中，需要根据具体情况选择合适的方法来判断Socket是否关闭。

若果出现不断重连的情况，可以参考 Netty:channelInactive、exceptionCaught方法不断触发