netty源码分析带你搞懂ChannelHandler事件传播顺序wbsnail的博客-

明确关键点：

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

1.pipeline初始化时，会创建两个哨兵Handler，即HeadContext、TailContext，head在头，tail在尾，我们添加的Handler就处于首尾Handler之间

       HeadContext可以是入站事件传播的起点，一定是出站事件传播的终点

       TailContext可以是出站事件传播的起点(为啥分为”可以是”与”一定是”，下文会有说明)

2.事件的传播起点、方向、目标：

       入站事件传播的起点为当前Handler或者HeadContext，方向为next，也就是往下一个，目标是InboundHandler

       出站事件传播的起点为当前Handler或者TailContext，方向为prev，也就是往回一个，目标是OutboundHandler

下面以这两点为主线进行剖析

Pipeline初始化，组装Handler链：

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

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

在Channel的构造方法中，会初始化一个ChannelPipeline

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

HeadContext、TailContext，就是这个pipeline中初始的两个Handler，也就是上面说的哨兵Handler，其中TailContext是InboundHandler，HeadContext既是InboundHandler，也是OutboundHandler

后续我们调用pipeline.addLast()方法添加的Handler都会处于HeadContext与TailContext之间，比如在我们添加了ByteToMessageDecoder(子类)、MessagetobyteEncoder(子类)、BizHandler三个Handler之后，Handler链就是这样(注意，Handler之间是双向连接的，从左往右是next方向，从右往左是prev方向)：

好了，Handler链已经组装好了，接下来就是事件传播了；我们以读写事件为例，在netty中，read事件由netty帮我们传播，write事件由我们自己传播

read事件传播：

先看read事件，我们得找到read事件的源头，Netty中，channel的所有IO事件由EventLoop处理，所以我们将视线转移到NioEventLoop中，NioEventLoop的run方法里就干了两件事情，1是轮询并处理selector事件，2是处理taskQueue中的任务，我们的重点放在1，从run开始看起，直到出现已就绪的read事件，开始将其传播，大致流程如下：

最后调用pipeline.fireChannelRead进行read事件传播，注意了！在netty中，事件传播有两类方法

1.Pipeline.*，比如fireChannelRead传播读事件、write传播写事件(还有一种Channel.fire*，实际上还是调用了Pipeline.fire*)

2.ChannelHandlerContext.*，比如fireChannelRead传播读事件、write传播写事件

这两类方法的唯一区别是传播的起点不一样，前者的起点是HeadContext(入站事件起点)、或者TailContext(出站事件起点)，后者的起点是当前Handler；

好了，我们接着看pipeline.fireChannelRead方法逻辑，方法体如下：

head！！！没错，就是HeadContext，pipeline中的第一个Handler，通过Pipeline.*方法传播入站事件时，就以HeadContext为起点，它会继续把读事件往下传播，寻找下一个Handler的逻辑如下图(AbstractChannelHandlerContext是ChannelHandler的上下文，一一对应的，找到ChannelHandlerContext就相当于找到了ChannelHandler)：

这个do while循环的意思很明确，一直往next方向找，直到第一个InboundHandler，调用其channelRead方法，对于我们上面的Handler链，就会首先找到ByteToMessageDecoder；ByteToMessageDecoder的channelRead方法会先调用子类的decode方法，然后继续传播事件，代码如下：为方便理解，我略去了一些内容，重点关注我红框标出的代码

fireChannelRead方法：

它调用的是ChannelHandlerContext.fire*，前面说了，这类方法的起点是当前Handler，传播的方向是next，寻找Handler的代码和上面贴的是同一份，我再贴过来：

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

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

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

2.Pipeline.fireChannelRead方法会以HeadContext为起点，向next方向找InboundHandler，在本例中，也就是ByteToMessageDecoder

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

4.该方法会以当前Handler为起点，向next方向找InboundHandler，在本例中，也就是BizHandler

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

write事件传播：

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

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

出站事件的方向与入站事件相反，是prev方向，也就是往回传播，目标是OutboundHandler，终点是HeadContext

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

对应我们前面说的，事件传播的两类方法：Pipeline.*、ChannelHandlerContext.*

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

Pipeline.write方法如下：

tail！！！没错，就是TailContext，pipeline的最后一个Handler，通过Pipeline.*方法传播出站事件时，就以TailContext为起点，它会继续把出站事件往下传播，查找下一个Handler的逻辑如下：

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

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

MessageToByteEncoder会先调用子类的encode方法，再调用ChannelHandlerContext.write方法传播write事件，会以当前Handler为起点，往prev方向找前一个OutboundHandler，也就是HeadContext，HeadContext是出站事件的终点，它会调用底层unsafe的write方法往netty的写缓冲区写入字节流，对于我们来说，write事件到此就结束了，本次write事件的传播过程大致如下：

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

2.channel.write方法会调到Pipeline.write，我们说过，它会以TailContext为起点，prev为方向，OutboundHandler为目标，查找下一个符合要求的Handler，也就是MessageToByteEncoder

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

4.ChannelHandlerContext.write方法以当前Handler为起点，prev为方向，OutboundHandler为目标，查找下一个符合要求的Handler，也就是出站事件的终点，HeadContext

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

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

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

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