Netty中ChannelHandler

pipeline和channelHandler 的分类

无论是从服务端来看，还是客户端来看，在 Netty 整个框架里面，一条连接对应着一个 Channel，这条 Channel 所有的处理逻辑都在一个叫做  的对象里面， 是一个双向链表结构，他和 Channel 之间是一对一的关系。

里面每个节点都是一个  对象，这个对象能够拿到和 Channel 相关的所有的上下文信息，然后这个对象包着一个重要的对象，那就是逻辑处理器 。

分类：

可以看到  有两大子接口：

第一个子接口是 ，从字面意思也可以猜到，他是处理读数据的逻辑，比如，我们在一端读到一段数据，首先要解析这段数据，然后对这些数据做一系列逻辑处理，最终把响应写到对端， 在开始组装响应之前的所有的逻辑，都可以放置在  里处理，它的一个最重要的方法就是 。读者可以将  的逻辑处理过程与 TCP 的七层协议的解析联系起来，收到的数据一层层从物理层上升到我们的应用层。

第二个子接口  是处理写数据的逻辑，它是定义我们一端在组装完响应之后，把数据写到对端的逻辑，比如，我们封装好一个 response 对象，接下来我们有可能对这个 response 做一些其他的特殊逻辑，然后，再编码成 ByteBuf，最终写到对端，它里面最核心的一个方法就是 ，读者可以将  的逻辑处理过程与 TCP 的七层协议的封装过程联系起来，我们在应用层组装响应之后，通过层层协议的封装，直到最底层的物理层。

这两个子接口分别有对应的默认实现，，和 ，它们分别实现了两大接口的所有功能，默认情况下会把读写事件传播到下一个 handler。

channelHandler 分为 inBound 和 outBound 两种类型的接口，分别是处理数据读与数据写的逻辑，可与 tcp 协议栈联系起来。

两种类型的 handler 均有相应的默认实现，默认会把事件传递到下一个，这里的传递事件其实说白了就是把本 handler 的处理结果传递到下一个 handler 继续处理。

inBoundHandler 的执行顺序与我们实际的添加顺序相同，而 outBoundHandler 则相反。

SimpleChanelInboundHandler与ChannelInboundHandlerAdapter

每一个Handler都一定会处理出站或者入站（也可能两者都处理）数据，例如对于入站的Handler可能会继承或者，而又是继承于，最大的区别在于会对没有外界引用的资源进行一定的清理，并且入站的消息可以通过泛型来规定。

对于两者关系：

对于ChannelInboundHandlerAdapter的实现，会实现ChannelInboundHandler中的所有方法：

但是我们可能只会重写一些我们感兴趣的方法来处理数据，这里使用的是适配器模式

对于SimpleChannelInboundHandler中：

 因此我们继承后，处理入站的数据我们只需要重新实现channelRead0方法，当channelRead真正被调用的时候我们的逻辑才会被处理。这里使用的是模板模式，让主要的处理逻辑保持不变，让变化的步骤通过接口实现来完成

  值得注意的是对于入站的数据，当被读取之后可能会执行ReferenceCountUtil.release(msg)释放资源。底层是实现ReferenceCounted，当新的对象初始化的时候计数为1，retain()方法实现其他地方的引用计数加1，release()方法实现应用减一，当计数减少到0的时候会被显示清除，再次访问被清除的对象会出现访问冲突。

  因此，当我们实现自己的Handler的时候如果希望将客户端发送过来的数据发送到客户端，可能在上述finally中已经释放了资源（writeAndFlush是异步处理），所以会出现异常情况。

  但是当我们实现的是类的时候，重写channelRead方法时，需要释放ByteBuf相关的内存，可以使用Netty提供了一个工具方法，ReferenceCountUtil.release()。

SimpleChannelInboundHandler和ByteToMessageDecoder

通常情况下，无论我们是在客户端还是服务端，当我们收到数据之后，首先要做的事情就是把二进制数据转换到我们的一个 Java 对象，所以 Netty 很贴心地写了一个父类，来专门做这个事情，下面我们来看一下，如何使用这个类来实现服务端的解码

当我们继承了  这个类之后，我们只需要实现一下  方法，这里的 in 大家可以看到，传递进来的时候就已经是 ByteBuf 类型，所以我们不再需要强转，第三个参数是  类型，我们通过往这个  里面添加解码后的结果对象，就可以自动实现结果往下一个 handler 进行传递，这样，我们就实现了解码的逻辑 handler。

和 都继承了类。

通过decode方法把ByteBuf 解码成业务需要的格式后向后传递。

也可以通过channelRead0方法把ByteBuf 解码成业务需要的格式，若需要向后传递，需要显示调用fireChannelRead。 则不需要。

基于 ByteToMessageDecoder，我们可以实现自定义解码，而不用关心 ByteBuf 的强转和 解码结果的传递。

基于 SimpleChannelInboundHandler，我们可以实现每一种指令的处理，不再需要强转，不再有冗长乏味的 if else 逻辑，不需要手动传递对象。

基于 MessageToByteEncoder，我们可以实现自定义编码，而不用关心 ByteBuf 的创建，不用每次向对端写 Java 对象都进行一次编码。

热爱技术才能学好技术

每天进步一点点