Netty学习之旅------源码分析ChannelPipeline实现原理
本文主要从如下方面展示：
- Netty bind源码分析
- ChannelPipline链式请求源码分析
1、Netty ServerBootstrap bind源码跟踪
本文将重点分析Netty服务端绑定端口流程。
1.1 入口程序
1.2 AbstractBootstarp的doBind方法
- 初始化一个通道，并注册，如果注册失败，直接返回。
- 如果初始化并立即注册成功，执行doBind0方法，进行绑定
- 如果未立即注册成功，则添加监听事件，等初始化并注册成功后，执行doBind0方法，这里是Netty对jdk Future模式进行的扩展，引入事件机制
1.2.1 AbstractBoostart initAndRegister方法
初始化一个Channel类实例，此处返回的是io.netty.channel.socket.nio.NioServerSocketChannel实例，然后调用init方法初始Channel,AbstractBootstrap中的init为抽象方法，有具体子类实现。Channel初始化后，就是将该通道注册到Selector上。
1.2.1.1 ServerBootstrap init方法
1.2.1.2 group().register 方法
根据Netty线程模型，group()返回的是EventLoopGroup，然后Netty会从该EventLoopGroup中获取下一个EventLoop来执行。由于程序入口使用的是NioServerSocketChannel,故本例最终会使用NioEventLoop来作为事件处理器来服务，这里的register方法，其实现在NioEventLoop的父类SingleThreadEventLoop中。
有关Channel的IO类操作，最终都会转发给Unsafe类去执行，直接进入到AbstractUnsafe中
register方法，确保绑定操作在通道所关联的事件处理器（EventLoop）中执行，真正注册方法为
接下来进入到doRegister,该类有具体的通道子类实现，这里我们关注的是NioServerSocketChannel类，在该类的父类AbstractNioChannel中实现：
完成Channel的注册外，需要调用管道的pipline.fireChannelRegistered,跟踪进去，最终将执行DefaultChannelHandlerInvoker的invokeChannelRegistered方法。该方法会执行ChannelInitializer的init
ChannelInitializer的channelRegistered()方法被执行，这里正是代码中初始化业务handler的地方了。
总结与问题引出：
1、以Nio为例，绑定操作，主要完成Channel到Selector的注册，Channel绑定监听端口。
2、再提线程模型，与Channel通道的操作，无论是绑定，还是读，或写的执行，都是放在与Channel绑定的
3、Netty的ChannelPipeline的核心原理或思想是基于处理链条的拦截机制，就像上文的sc.pipeline().addLast( ChannelHander )，将各个逻辑处理单元(Handler)随链条一个一处理，第一个节点为HeaderHandler,尾部为TailHandler。
2、ChannelPipeline相关源码分析
2.1 ChannelPipeline类图设计
设计理念：ChannelPipeline管道，提供相应的API,增加ChannelHander形成处理链条，在DefaultChannelPipeline中并不是用一个LikedList
以下实例方法来自DefaultChannelPipeline类：
public ChannelPipeline fireChannelRegistered() {
head.fireChannelRegistered();
return this;
}
@Override
public ChannelPipeline read() {
tail.read();
return this;
}
@Override
public ChannelFuture write(Object msg) {
return tail.write(msg);
}从上述方法，不难看出,ChannelPipeline的实现源码，就是沿着调用链向上或向下传播事件并执行之。
这里会涉及到另外一个概念，inbound与outbound，输入流与输出事件。
Netty关于事件是inbound还是outbound，统一封装在AbstractChannelHandlerContext，具体如下图：
为了更好的理解Netty事件流的方向，以服务器的视角：我们按照职责，一般会通过如下顺序编排ChannelHandler链：
解码器--->编码器---->业务handler(权限验证)---->具体handler。
首先，Netty服务器首先接受客户端的连接请求(MASK_CONNECT),然后客户端发送数据，服务器接受客户端的请求信息（CHANNEL_READ）,接受请求的数据依次通过如下handler( 解码器handler、业务handler(权限验证)、具体业务handler，在此过程中会忽略编码器handler)。然后服务器处理，想客户端发送响应数据（CHANNEL_WRITE、CHANNEL_FLUSH）事件。
异常抛出（EXCEPTION_CAUGHT）,通道注册（CHANNEL_REGISTEED）、通道取消注册（CHANNEL_UNREGISTED)、通道激活(CHANNEL_ACTIVIE,即调用bind方法后)、CHANNEL_INACTIVE(通道取消激活)、通道读（CHANNEL_READ)、通道读完成（CHANNEL_READ_COMPLETE）、通道读写状态发生改变（CHANNEL_WRITABLITY_CHANGED）、用户自定义事件。这些事件的顺序，一般是从IO线程触发的。handler的处理链条是从header开始，依次向后面合适的处理器（输入职责，还是输出职责的handler）。
端口绑定（MASK_BIND）、连接（MASK_CONNECT)、通道端口连接（MASK_DISCONNECT）、通道关闭（MASK_CLOSE）、读写等。
这类事件，一般是从尾部开始处理。
怎么区分一个Handler是一个输入性质的handler还是一个输出性质的handler？根据事先的事件方法来决定。上面这些掩码，其实在ChannelHandler中对应一个事件方法。ChannelPipeline在执行事件的时候，会根据Handler实现的方法来选择合适的ChannelHandler执行。如果一个handler同事实现了输入流事件，输出流事件，在Netty5中，这个handler永远也不会被执行到。首先，如果一个handler只继承ChannelHandlerAdapter，而不重写任何方法，那该Handler永远不会被执行到，因为Netty5使用@Skip注解，将所有的事件方法默认是取消的。其选择一个Handler的代码如下：
private AbstractChannelHandlerContext findContextInbound() {
AbstractChannelHandlerContext ctx = this;
do {
ctx = ctx.next;
} while ((ctx.skipFlags & MASKGROUP_INBOUND) == MASKGROUP_INBOUND);
return ctx;
}
private AbstractChannelHandlerContext findContextOutbound() {
AbstractChannelHandlerContext ctx = this;
do {
ctx = ctx.prev;
} while ((ctx.skipFlags & MASKGROUP_OUTBOUND) == MASKGROUP_OUTBOUND);
return ctx;
}通过上面的分析与讲解，其实ChannelPipeline并没有什么高深的地方，其设计哲学就是职责链模式。将不同的Handler编排成一条执行链。本文通过bind方法的详解，基本梳理了Netty方法调用的整条调用链。然后从ChannelPipeline的类图引出ChannelPipeline的设计哲学。下文将重点以Channel的read,writer方法，开启Chanel部门的源码分析，编码解码的核心原理。
欢迎加笔者微信号(dingwpmz)，加群探讨，笔者优质专栏目录：
1、源码分析RocketMQ专栏(40篇+)
2、源码分析Sentinel专栏(12篇+)
3、源码分析Dubbo专栏(28篇+)
4、源码分析Mybatis专栏
5、源码分析Netty专栏(18篇+)
6、源码分析JUC专栏
7、源码分析Elasticjob专栏
8、Elasticsearch专栏
9、源码分析Mycat专栏