明确关键点：
要搞懂事件在多个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中，事件传播有两类方法
- 通过Pipeline传播，比如pipeline.fireChannelRead传播读事件、pipeline.write传播写事件(还有些地方通过channel传播，实际上也是委托给Pipeline)
- 通过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)效果还一样吗？