netty源码分析_带你搞懂ChannelHandler事件传播顺序

明确关键点：

要搞懂事件在多个channelHandler间的传播顺序，有几个关键点需要明确

0.channelHandler分为两大类，即InboundChannelHandler和OutboundChannelHandler，InboundChannelHandler用于处理入站事件(如read)，OutboundChannelHandler处理出站事件(如write)

1.所有channelHandler由channelPipeline统一管理，pipeline维护一个双向链表结构(下文称为channelHandler链)，添加移除channelHandler都会作用到链表上

2.channelPipeline初始化时，会默认创建两个哨兵channelHandler，即HeadContext、TailContext，HeadContext在链表头部，TailContext在尾部，我们添加的channelHandler总是处于二者之间

比如我们通过SocketChannel.pipeline().addLast方法依次添加了ByteToMessageDecoder、MessagetobyteEncoder、BizHandler之后，channelHandler链就是这样

(ps:标红的inbound、outbound表示该channelHandler属于InboundChannelHandler还是OutboundChannelHandler，当然了，也可以二者都属于)

(ps:从左往右是next方向，从右往左是prev方向)

3.事件传播会以某个channelHandler为起点，沿着channelHandler链、向next或者prev方向查找符合要求的目标channelHandler，然后将事件传给它，目标channelHandler可以接着传播，也可以停止传播

• 在netty中，事件传播有两类方法

1. 通过Pipeline传播，比如pipeline.fireChannelRead传播读事件、pipeline.write传播写事件(还有些地方通过channel传播，实际上也是委托给Pipeline)
2. 通过ChannelHandlerContext传播，比如ChannelHandlerContext.fireChannelRead传播读事件、ChannelHandlerContext.write传播写事件

• 通过Pipeline传播入站事件时，起点为HeadContext，通过ChannelHandlerContext传播入站事件时，起点为当前channelHandler(该ChannelHandlerContext对应的channelHandler就是当前channelHandler)；传播的方向为next(从左往右)，目标是InboundHandler(也就是只传给InboundHandler)
• 通过Pipeline传播出站事件时，起点为TailContext，通过ChannelHandlerContext传播出站事件时，起点为当前channelHandler；传播的方向为prev(从右往左)，目标是OutboundHandler(也就是只传给OutboundHandler)

下面进行详细说明

channelHandler链的构造：

服务端/客户端启动时，会初始化channelPipeline，channelPipeline初始化时会创建一个channelHandler链，结构为双向链表；(ps:这里服务端客户端逻辑一致)

就拿服务端来说，服务端的启动入口大家都知道，是ServerBootstrap.bind(port)方法

bind方法首先会通过反射创建一个Channel，Channel初始化过程中会创建一个Pipeline，这个过程如下图：

在NioServerSocketChannel父类AbstractChannel的构造方法中，会初始化一个ChannelPipeline

newChannelPipeline会创建一个DefaultChannelPipeline实例，其构造方法如下：

HeadContext、TailContext，就是上面说的哨兵，通过next/prev属性连接起来，其中TailContext是InboundHandler，HeadContext既是InboundHandler，也是OutboundHandler

后续我们调用pipeline.addLast()方法添加的channelHandler都会处于HeadContext与TailContext之间

channelHandler链组装好之后，接下来就是事件传播了；我们以读写事件为例，在netty中，read事件由netty帮我们传播，write事件由开发者传播

read事件传播：

先看read事件，我们得找到read事件的源头，Netty中，channel的所有IO事件都由EventLoop处理，所以我们将视线转移到NioEventLoop中，NioEventLoop的run方法里就干了两件事情

1是轮询并处理selector事件，2是处理taskQueue中的任务，我们的重点放在1，从run开始，直到出现已就绪的read事件，开始将其传播，大致流程如下：

最后调用pipeline.fireChannelRead进行read事件传播，方法体如下：

head！！！没错，就是HeadContext，通过Pipeline传播入站事件时，就以HeadContext为起点，它会找到下一个inboundHandler，然后将事件传播给它：

(AbstractChannelHandlerContext是ChannelHandler的上下文，一一对应的，找到ChannelHandlerContext就相当于找到了ChannelHandler)

这个do while会一直往next方向找，直到第一个InboundHandler，调用其channelRead方法，对于我们上面的Handler链，就会首先找到ByteToMessageDecoder；

ByteToMessageDecoder的channelRead方法会先调用子类的decode方法，然后继续传播事件：

fireChannelRead方法：

它调用的是ChannelHandlerContext.fire*，前面说了，通过ChannelHandlerContext传播事件的起点是当前channelHandler，传播的方向是next，代码和上面贴的是同一份，我再贴过来：

会往next方向，找到下一个InboundHandler，也就是我们的BizHandler

通常情况下，BizHandler的channelRead方法中，我们不会再继续往下传播read事件了，read事件到此结束，所以本次read事件的传播过程就是这样：

1.NioEventLoop轮询出就绪的read事件后，调用Pipeline.fireChannelRead方法传播事件

2.通过Pipeline传播读事件时，会以HeadContext为起点，向next方向，查找下一个InboundHandler，在本例中，也就是ByteToMessageDecoder

3.在解码出Message后，ByteToMessageDecoder会调用ChannelHandlerContext.fireChannelRead方法传播事件

4..通过ChannelHandlerContext传播读事件时，会以当前channelHandler为起点，向next方向，查找下一个InboundHandler，在本例中，也就是BizHandler

5.BizHandler中我们一般不会继续传播读事件，读事件结束

write事件传播：

再来看看write事件，原理与上面的read事件类似，区别就是方向相反、目标不同！

入站事件的方向是next方向，目标是InboundHandler

出站事件的方向是prev方向，目标是OutboundHandler，终点是HeadContext

正常情况下，write事件由我们开发者触发，分为两种方式：

对应我们前面说的，事件传播的两类方法：ctx.write对应ChannelHandlerContext，ctx.channel().write对应Pipeline

拿ctx.channel().write来说，流程大致如下：

Pipeline.write方法如下：

tail！！！没错，就是TailContext，pipeline的最后一个channelHandler，通过Pipeline传播出站事件时，以TailContext为起点，它会找到下一个outboundHandler，然后将事件传播给它：：

可以看到，传播方向与read相反，往prev方向找前一个OutboundHandler，我把channelHandler链再贴过来

TailContext先找到BizHandler，发现不是OutboundHandler，再找到MessageToByteEncoder，发现是OutboundHandler，调用其write方法：

MessageToByteEncoder会先调用子类的encode方法，再调用ChannelHandlerContext.write方法传播write事件

ChannelHandlerContext.write方法会以当前channelHandler为起点，往prev方向找前一个OutboundHandler，也就是HeadContext

HeadContext是出站事件的终点，它会调用底层unsafe的write方法往netty的写缓冲区写入字节流，对于我们来说，write事件到此就结束了，本次write事件的传播过程大致如下：

1.BizHandler中调用ctx.channel().write(msg)传播write事件

2.channel.write方法会调用Pipeline.write，通过Pipeline传播写事件时，会以TailContext为起点，向prev方向，查找下一个OutboundHandler，也就是MessageToByteEncoder

3.MessageToByteEncoder调用完子类的encode方法将消息编码后，继续调用ChannelHandlerContext.write(msg)传播事件

4.通过ChannelHandlerContext传播写事件时，会以当前channelHandler为起点，向prev方向，查找下一个OutboundHandler，也就是出站事件的终点，HeadContext

5.HeadContext调用底层的unsafe将消息写入缓冲区，写事件结束

如果在BizHandler中，调用的是ctx.write方法，那起点就不是TailContext了，而是当前Handler，往回找到下一个满足条件的Handler，也就是MessageToByteEncoder，对本例来说，效果一样

如果在往pipeline中添加Handler时，把MessageToByteEncoder放到BizHandler后面，也就是这样：

你想一想，在BizHandler里调用ctx.write(msg)和ctx.channel().write(msg)效果还一样吗？