ChannelHandler 源码分析（二十五）

快来打我* 2022-10-29 14:20 204阅读 0赞

今天我们进行ChannelHandler 源码分析：

简介：

ChannelHandler  类似于  Servlet  的  Filter  过滤器，负责对  I/O  事件或者  IO  操作进行拦截和处理，它可以选择性地拦截和处理自己感兴趣的事件，也可以透传和终止事件的传递。 基于 ChannelHandler  接口，用户可以方便地进行业务逻辑定制，例如打印日志、统一封装异常信息、性能统计和消息编解码等。

ChannelHandler  支持注解，我们常用的注解： @Sharable:多个  ChannelPipeline  共用同一个  ChannelHandler 。

***核心类关系图一：***

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

***核心类关系图二：***

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

***1、ChannelHandlerAdapter***

对于大多数的  ChannelHandler  会选择性地拦截和处理某个或者某些事件，其他的事件会忽略，由下一个 ChannelHandler  进行拦截和处理。这就会导致一个问题 : 用户 ChannelHandler 必须要实现  ChannelHandler  的所有接口，包括它不关心的那些事件处理接 口，这会导致用户代码的冗余和臃肿，代码的可维护性也会变差。为了解决这个问题，Netty  提供了  ChannelHandlerAdapter  基类，它的实现要么就是事件透传，要么就是空实现，如果用户 ChannelHandler  关心某个事件，只需要覆盖 ChannelHandlerAdapter 对应的方法即可，对于不关心的，可以直接继承使用父类的方法，这样子类的代码就会非常简洁和清晰。 我们的 ChannelHandler  都是直接继承自  ChannelHandlerAdapter 、ChannelInboundHandlerAdapter、 ChannelOutboundHandlerAdapter ，开发起来非常简单和高效。ChannelInboundHandlerAdapter 里实现都是通过  fireXXX ，进行事件透传， ChannelOutboundHandlerAdapter 里的实现都是调用  ChannelHandlerContext  中的对应方法。

***2、ChannelHandler***  ***子类***

相对于  ByteBuf  和  Channel ， ChannelHandler  的类继承关系稍微简单些，但是它的子类非常多。由于 ChannelHandler  是  Netty  框架和用户代码的主要扩展和定制点，所以它的子类种类繁多、功能各异。

系统 ChannelHandler  主要分类如下 :

1)、ChannelPipeline  的系统  ChannelHandler ，用于  I/O  操作和对事件进行预处理，对于用户不可见，这类 ChannelHandler  主要包括  HeadHandler  和  TailHandler 。

2)、编解码  ChannelHandler ，包括  ByteToMessageCodec 、 MessageToMessageDecoder  等，这些编解码类本身又包含多种子类。

3)、其他系统功能性  ChannelHandler ，包括流量整型  Handler 、读写超时  Handler 、日志  Handler等。

4)、协议编解码  Handler ， Netty  事先实现了很多协议的  ChannelHandler ，比如  Http  协议相关、SSL  相关等等。

ByteToMessageDecoder  和  MessageToByteEncoder  是我们用的比较多的两个ChannelHandler 的子类，我们挑这两个子类来看看里面关键的方法。

3、ByteToMessageDecoder

ByteToMessageDecoder （ public abstract class ByteToMessageDecoder extends ChannelInboundHandlerAdapter ）用于将  ByteBuf  转换成  Message ， message  可以是  POJO  等等，转换后继续在 ChannelPipeline  中往后面的入站  Handler  传递， ByteToMessageDecoder  继承自 ChannelInboundHandlerAdapter,需要开发者实现的是  decode  方法。 decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) 方法里， in  是用来读取的数据，out  是我们转换后的对象列表。既然是 ByteToMessage ，很明显，关键的方法是  channelRead：

@Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        if (msg instanceof ByteBuf) {
            CodecOutputList out = CodecOutputList.newInstance();
            try {
                ByteBuf data = (ByteBuf) msg;
                first = cumulation == null;
                if (first) {
                    cumulation = data;
                } else {
                    cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
                }
                callDecode(ctx, cumulation, out);
            } catch (DecoderException e) {
                throw e;
            } catch (Exception e) {
                throw new DecoderException(e);
            } finally {
                if (cumulation != null && !cumulation.isReadable()) {
                    numReads = 0;
                    cumulation.release();
                    cumulation = null;
                } else if (++ numReads >= discardAfterReads) {
                    // We did enough reads already try to discard some bytes so we not risk to see a OOME.
                    // See https://github.com/netty/netty/issues/4275
                    numReads = 0;
                    discardSomeReadBytes();
                }
    
                int size = out.size();
                decodeWasNull = !out.insertSinceRecycled();
                fireChannelRead(ctx, out, size);
                out.recycle();
            }
        } else {
            ctx.fireChannelRead(msg);
        }
    }

从总体结构来说，

if (msg instanceof ByteBuf) \{

//  （略）这里是第二层结构

\} else \{

ctx.fireChannelRead(msg);

很明显，判断传入类型是否为  ByteBuf ，类型符合则处理，不符合则透传。 在具体的处理部分中，创建一个 CodecOutputList( 也是一种  list) 保存转码后的对象列表。 因为有粘包和半包需要处理，使用 ByteBuf  型的  cumulation  来保留处理不完的  ByteBuf ，同时使用一个专门的接口 Cumulator  来负责合并。之后调用 callDecode(ctx, cumulation, out),callDecode 中循环调用我们要实现的抽象方法 decode(ctx,in,out)来解码。然后将解码后的对象通过  fireChannelRead  交给后面的  Handler  进行处理

4、MessageToByteEncoder

MessageToByteEncoder  用于将  Message  转换成  ByteBuf ，转换后继续在  ChannelPipeline 中往前面的出站 Handler  传递， MessageToByteEncoder  继承自

ChannelOutboundHandlerAdapter, 需要开发者实现的是  encode  方法。里面关键的就是 write  方法

@Override
    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
        ByteBuf buf = null;
        try {
            if (acceptOutboundMessage(msg)) {
                @SuppressWarnings("unchecked")
                I cast = (I) msg;
                buf = allocateBuffer(ctx, cast, preferDirect);
                try {
                    encode(ctx, cast, buf);
                } finally {
                    ReferenceCountUtil.release(cast);
                }
    
                if (buf.isReadable()) {
                    ctx.write(buf, promise);
                } else {
                    buf.release();
                    ctx.write(Unpooled.EMPTY_BUFFER, promise);
                }
                buf = null;
            } else {
                ctx.write(msg, promise);
            }
        } catch (EncoderException e) {
            throw e;
        } catch (Throwable e) {
            throw new EncoderException(e);
        } finally {
            if (buf != null) {
                buf.release();
            }
        }
    }

其中的逻辑是比较简单的，判断消息是否是类型匹配的，不是就直接往前面的出站 handler 传递，是的话会申请一个缓冲区，然后调用开发者实现 encode 方法进行编码，编码成功，通过 ctx 往前面的出站 Handler 进行传递，并会释放消息。如果编码失败，就往前写 一个空缓冲区，把申请的缓冲区释放了。

ChannelHandler 源码分析分析完成，下篇分析Future 和 Promise 源码，敬请期待！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221024/358d44705b36443ca3ee3fba008e2a26.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221024/be05bae5d02a45e69cca8a83b81ddfb5.png