inBound事件
当发生某个IO事件的时候，例如链路建立，链路关闭，读取操作完成（register,read,active）等，都会产生一个事件，事件在pipeline中传播和处理。pipeline中以fireXXX命名的方法都是从IO线程向用户业务Handler的inBound事件，它们的实现因功能而异，但是处理步骤类似。如下：
（1）调用HeadHandler对应的fireXXX方法。
（2）执行事件相关的逻辑操作。
当调用ChannelHandlerContext.fireXXX（fireChannelRead()）方法的时候，事件会从当前节点向下进行传播，就是找到下一个ChannelInBoundHandler，然后调用ChannelInBoundHandler的channelXXX方法，如果不覆盖channelXXX方法的话，默认会将这个消息在pipeline上从头到尾进行传播，最后会调用到Tail节点的channelXXX方法，如果说有消息一直调用到Tail节点的channelXXX方法，说明前面的channelHandler没有处理消息，使得消息一直到了尾节点，尾节点需要进行一定的释放，防止内存泄漏。
SimpleChannelInBoundHandler的channelRead0方法会帮助自动释放ByteBuf，它的channelRead方法调用channelRead0()并且释放ByteBuf。
outBound事件
由用户线程或者代码发起的IO操作被称做outBound事件。ChannelOutBoundHandler的添加顺序和事件传播的顺序是相反的。而outBound事件是寻找下一个ChannelOutBoundHandler，调用该handler的方法，最终会从Tail节点传播到Head节点。
总结：每次使用pipeline传播调用方法时，是从头结点或者尾节点开始传播，而使用ChannelHandlerContext则是从当前节点开始传播。
异常传播
异常的传播并不区分是inBoundHandler还是outBoundHandler，异常都会在上面进行传播。异常的传播顺序是和handler添加的顺序相关（一样）。默认情况下异常的传播是直接拿到当前节点的下一个节点，最终会传播到Tail节点的exceptionCaught()，Tail节点最终会打印这个exception，通知这个异常并没有被处理。如果说我们需要对异常做一个处理的话，最好在pipeline最后添加一个异常处理器，最终可以对异常进行一个统一的处理。
