Netty源码死磕(ChannelPipeline的执行过程)
引言
上文有提到如果Selector轮询到网络IO事件了，则会调用该Channel对应的ChannelPipeline来依次执行对应的ChannelHandler。
ChannelPipeline和ChannelHandler的关系
那么这里的ChannelPipeline和ChannelHandler之间到底是什么关系呢？
其实我们可以理解为类似于一个过滤器模式，其中ChannelPipeline是一个存放各种过滤器的管道容器，而ChannelHandler则对应着单个过滤器实体
执行流程
我们来看下ChannelPipline的工作流程
NioEventLoop触发读事件，会调用SocketChannel所关联的ChannelPipline- 由上一步读取到的消息会在
ChannelPipline中依次被多个ChannelHandler处理 - 处理完消息会调用
ChannelHandlerContext的write方法发送消息，发送的消息同样也会经过ChannelPipline中的多个ChannelHandler处理
上面的流程其实主要分成了两步，触发读事件和写事件。对应这两种事件，Netty把ChannelHandler也分为了两大类
ChannelInboundHandler顾明思义，负责处理链路读事件的Handler。通常由IO线程触发ChannelOutboundHandler，负责链路写事件的Handler
也就是说当IO线程触发读事件时，只会调用ChannelInboundHandler的实现handler
下面我们看下ChannelHandler在ChannelPipline中是一个什么样的结构
可以看到ChannelHandler在加入ChannelPipline之前会被封装成一个ChannelHandlerContext节点类加入到一个双向链表结构中。除了头尾两个特殊的ChannelHandlerContext实现类，我们自定义加入的ChannelHandler最终都会被封装成一个DefaultChannelHandlerContext类。
当有读事件被触发时，ChannelHandler(会筛选类型为ChannelInboundHandler的Handler) 的触发顺序是 HeaderContext -> TailContext
当有写事件被触发时，ChannelHandler(会筛选类型为ChannelOutboundHandler的Handler) 的触发顺序与读事件相反是 TailContext -> HeaderContext
总结
本文比较简短，主要是为了理清ChannelPipeline和ChannelHandler的关系，以及ChannelHandler在ChannelPipeline中的执行过程是怎样的
