Netty源码阅读笔记1：ChannelPipeline责任链模式

工作中接触到很多框架底层都采用了Netty作为通信组件，比如阿里的dubbo，蘑菇街的tesla等，于是对Netty产生了好奇，想看一看这个传说中的基于事件的异步IO框架到底是怎么实现的。经过断断续续地对Netty对源码的阅读，渐渐的有了一些体会，记下来，怕自己忘记。

关于Netty的介绍这里就不写了，官网已经介绍地很详细了：netty官网 本文只谈自己阅读netty源码的一些感想。

初读netty源码的时候，感觉一头雾水，找不到真正处理业务逻辑的地方，Channel、ChannelPipeline、ChannleHandlerContext、ChannelHandlerInvoker等一大堆类感觉很混乱，其实它们之间的关系和职责还是挺清晰的，如下图所示：

各个类的职责如下：
Channel：封装了jdk原生的channel，提供统一的API，作为其它各个功能组件的容器。

ChannelPipeline：责任链模式的核心组件，ChannelHandler的容器，按顺序组织各个ChannelHandler，并在它们之间转发事件。

ChannelHandlerContext：封装一个具体的ChannelHandler，并为ChannelHandler的执行提供一个线程环境（ChannelHandlerInvoker）可以理解为ChannelPipeline链路上的一个节点，节点里面包含有指向前后节点的指针，事件在各个ChannelHandler之间传递，靠的就是ChannelHandlerContext。

ChannelHandlerInvoker：顾名思义，是ChannelHandler的一个Invoker，它存在的意义是为ChannelHandler提供一个运行的线程环境，默认的实现DefaultChannelHandlerInvoker有一个EventExecutor类型的成员，就是Netty的EventLoop线程，所以默认ChannelHandler的处理逻辑在EventLoop线程内。当然也可以提供不同的实现，替换默认的线程模型。

ChannelHandler： 真正对IO事件作出响应和处理的地方，也是Netty暴露给业务代码的一个扩展点。一般来说，主要业务逻辑就是以自定义ChannelHandler的方式来实现的。

ChannelPipeline 有一个著名的Inbound和outBound事件流模型，javadoc里面的图已经能说明问题了，但是可能还是有很多人搞不清头和尾，因此，自己画了下面的图：

最接近底层socket的是head，最接近业务层的是tail，业务方配置的handler都是基于两者之间的。

关于ChannelPipeline，只需要了解DefaultChannelPipeline这个默认的实现类，这个类其实就是一个链表管理类，管理者每一个ChannelHandlerContext类型的节点，从它的addFirst、addLast、remove等成员方法就可以看出来。

ChannelHandler是一个顶级接口，有两个子接口ChannelInboundHandler和ChannelOutboundHandler分别处理read和write相关的IO事件，为了便于业务方实现，两个子接口分别有一个简单的Adapter实现类，所有方法的默认实现都是代理给ChannelHandlerContext类（其实是不关心事件，直接转发给pipeline中下一个节点的handler来处理）。业务方实现自己的ChannelHandler时，推荐继承相应的Adapter类，只实现自己关心的事件的处理方法。