明确关键点：
要搞懂事件在多个ChannelHandler间的传播顺序，有两个关键点需要明确
1.pipeline初始化时，会创建两个哨兵Handler，即HeadContext、TailContext，我们添加的Handler处于这两个哨兵Handler之间，HeadContext可以是入站事件传播的起点，一定是出站事件传播的终点
TailContext可以是出站事件传播的起点(为啥分为"可以是"与"一定是"，下文会有说明)
2.事件的传播起点、方向、目标：
入站事件传播的起点为当前Handler或者HeadContext，方向为next，也就是往下一个，目标是InboundHandler
出站事件传播的起点为当前Handler或者TailContext，方向为prev，也就是往回一个，目标是OutboundHandler
Pipeline初始化，组装Handler链：
下面以这两点为主线进行剖析，服务端的启动入口大家都知道，是Bootstrap.connect
connect方法首先会通过反射创建一个Channel，这个过程如下图：
在Channel的构造方法中，会为该Channel初始化一个DefaultChannelPipeline，这个类的构造方法如下：
HeadContext、TailContext，就是这个pipeline中初始的两个Handler，也就是上面说的哨兵Handler，其中TailContext是InboundHandler，HeadContext既是InboundHandler，也是OutboundHandler
后续我们在调用pipeline.addLast()方法添加的Handler都会处于HeadContext与TailContext之间，比如在我们添加了ByteToMessageDecoder(子类)、MessagetobyteEncoder(子类)、BizHandler三个Handler之后，Handler链就是这样(注意，Handler之间是双向连接的，从左往右是next方向，从右往左是prev方向)：
read事件传播：
好了，Handler链已经组装好了，接下来就是事件传播了
我们以读写事件为例，在netty中，read事件由netty帮我们传播，write事件由我们自己传播
先看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为起点，它会继续把读事件往下传播
这个do while循环的意思很明确，一直往next方向找，直到第一个InboundHandler，调用其channelRead方法，对于我们上面的Handler链，就会首先找到ByteToMessageDecoder；ByteToMessageDecoder的channelRead方法会先调用子类的decode方法，然后继续传播事件，代码如下：为方便理解，我略去了一些内容，重点关注我红框标出的代码
fireChannelRead方法：
它调用的是ChannelHandlerContext.fire*，前面说了，这类方法的起点是当前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
正常情况下，write事件由我们开发者触发，分为两种方式：
对应我们前面说的，事件传播的两类方法：Pipeline.write、ChannelHandlerContext.write
拿ctx.channel().write来说，流程大致如下：
Pipeline.write方法如下：
tail！！！没错，就是TailContext，pipeline的最后一个Handler，通过Pipeline.*方法传播出站事件时，就以TailContext为起点，它会继续把读事件往下传播
可以看到，传播方向与read相反，往回找前一个OutboundHandler，我把Handler链再贴过来
TailContext先找到BizHandler，发现不是OutboundHandler，再找到MessageToByteEncoder，发现是OutboundHandler，调用其write方法：
先调用子类的encode方法，再调用ChannelHandlerContext.write方法，继续往prev方向找前一个OutboundHandler，也就是HeadContext，HeadContext会调用底层unsafe的write方法往netty的写缓冲区写入字节流，对于我们来说，write事件到此就结束了，所以本次write事件的传播过程大致如下：
1.BizHandler中调用ctx.channel().write
2.以TailContext为起点，prev为方向，OutboundHandler为目标，查找下一个符合要求的Handler，也就是MessageToByteEncoder
3.MessageToByteEncoder调用完子类的encode方法将消息编码后，继续调用ctx.write传播事件
4.ctx.write方法以当前Handler为起点，prev为方向，OutboundHandler为目标，查找下一个符合要求的Handler，也就是HeadContext
5.HeadContext调用底层的unsafe将消息写入缓冲区，写事件结束
如果，在BizHandler中，调用的是ctx.write方法，那就不会走到TailContext了，而是以当前Handler为起点，往后找到下一个满足条件的Handler，也就是MessageToByteEncoder，对本例来说，效果一样
如果在往pipeline中添加Handler时，把MessageToByteEncoder放到BizHandler后面，也就是这样：
你想一想，ctx.write和ctx.channel().write效果还一样吗？
网友评论