概述
上面几篇文章中会经常看到执行到某个地方，然后就开始在ChannelPipeline传播事件，再由ChannelPipeline责任链上的一个个ChannelHandler去处理，所以ChannelPipeline和ChannelHandler才是用户真正处理各种业务的地方，主要包括：数据包编解码，业务处理，数据包写入通道。
每个Channel都会维护一个ChannelPipeline，而ChannelPipeline其实是包含头尾指针的双向链表，里边的的每个节点都是由ChannelHandler封装成的ChannelHandlerContext上下文，ChannelHandlerContext中除了封装ChannelHandler还包含了一些所关联的组件实例。
ChannelHandler处理器分为两大类：一类是ChannelInboundHandler通道入站处理器，一类是ChannelOutboundHandler通道出站处理器，均继承自ChannelHandler接口。两个接口都有自己的处理适配器，分别是ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter，实现自己的业务只需继承这两个适配器即可。
入站事件在ChannelPipeline中由头指针向尾指针传播，只处理Inbound类型的Handler，出站事件由尾指针向头指针传播，只处理Outbound类型的Handler。贴张官方注释的图：
ChannelPipeline添加节点
前面文章已经分析过了，Channel初始化时会初始化一个ChannelPipeline，初始化代码如下：
绑定所属的Channel，声明一个succeededFuture和voidPromise用来处理异步操作。然后创建TailContext类型的尾指针，HeadContext的头指针，将其串成链表。TailContext和HeadContext都继承自AbstractChannelHandlerContext，内部维护了unsafe的对象。
ChannelPipeline提供了一系列增删ChannelHandler节点的方法，此处以最常用的addLast为例：
首先检查Handler是否重复添加，然后创建一个DefaultChannelHandlerContext对象封装目标handler，并将相关联的组件添加进去。然后进入addLast0将其加入链表：
将获得的DefaultChannelHandlerContext插入链表的尾部，尾结点的上一个位置。然后回到主方法，判断此时Channel是否注册到EventLoop，如果没有则新增一个任务注册后添加，如果已经注册，判断是不是当前线程是不是EventLoop线程，将其添加到任务队列中，启动线程后执行。如果已经注册且为EventLoop线程则直接触发HandlerAdd事件。
ChannelPipeline事件传播
ChannelPipeline的事件传播主要从调用fireIN_EVET()方法开始，此处以常用的fireChannelRead()为例：
调用上下文DefaultChannelHandlerContext的invekeChannelRead方法，将数据和ChannelPipeline的头结点传入：
获取当前context所绑定的EventLoop线程，然后判断当前线程是否是绑定的EventLoop线程，是则直接执行invokeChannelRead方法，不是则封装成任务放到任务队列中，等待线程轮询执行，然后进入invokeChannelRead方法：
判断是否需要执行handler，需要则获取handler执行其channelRead，否则继续向下传播。因为此时是头结点，进入其channelRead方法，直接就向下传播：
进入context的传播方法如下：
在findContextInbound()方法中寻找下一个handler如下：
然后又进入了invokeChannelRead方法，进入了传播循环：
当不再调用
ctx.fireChannelRead(msg)向下传播时，传播停止，或者当传播到尾结点是，释放资源，结束传播，尾结点channelRead如下：
Outbound事件发生时，会触发Outbound类型handler，流程相似，区别是从尾节点开始，向头结点传播。
