Netty框架之ChannelPipeline
本文主要记录下本人看Netty源码中关于ChannelPipeline的细节问题，为原创内容，如有文中有书写或其他问题，请留言指导修正，互相交流，共同进步，本人QQ：417213902。
认识ChannelPipeline
image.png
ChannelPipeline内部是实现类似责任链的调用，每一个handler记录下一个handler，感觉有点像servlet中的Filter链。
源码解读
image.png
首先，看下ChannelPipeline接口主要继承ChannelInboundInvoker 和ChannelOutboundInvoker这两个接口
- ChannelInboundInvoker ：AbstractChannelHandlerContext中实现了该接口，并调用ChannelInboundHandler的接口，从而实现真正的调用
- ChannelOutboundInvoker ：AbstractChannelHandlerContext中实现了该接口，并调用ChannelOutboundHandler的接口，从而实现真正的调用
- ChannelInboundHandler：对从客户端发往服务端的报文进行处理，一般用来执行解码、读取客户端数据、进行业务处理等，按照注册的先后顺序执行，若要自行实现ChannelInboundHandler接口，直接继承ChannelInboundHandlerAdapter，因为此类已经有默认接口实现。
- ChannelOutboundHandler：对从服务端发往客户端的报文进行处理，一般用来进行编码、发送报文到客户端，按照注册的先后顺序逆序执行 ，同上。
其次，来讲下ChannelPipeline的初始化，以下代码是Netty-4.1官方提供的Example 中服务端代码(io.netty.example.echo.EchoServer)，这里做了不少的事情，这里除了ChannelPipeline初始化，其他内容会在其他的文章中做阐述，这里我们主要看 .channel(NioServerSocketChannel.class)
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 100)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
if (sslCtx != null) {
p.addLast(sslCtx.newHandler(ch.alloc()));
}
//p.addLast(new LoggingHandler(LogLevel.INFO));
p.addLast(new EchoServerHandler());
}
});
ChannelFuture f = b.bind(PORT).sync();
f.channel().closeFuture().sync();
} finally {
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
image.png
这是NioServerSocketChannel的类结构层次图，这里我们主要看AbstractChannel这个抽象类，查看其构造方法，这里同时也实例化了一个DefaultChannelPipeline。
image.png
它其实是Netty中ChannelPipeline接口的具体实现类，是ChannelPipeline的核心类，责任链的一系列实现基本都是通过这个类来操作。
image.png
我们再来看下DefaultChannelPipeline的构造方法中实例化了两个类，分别是TailContext和HeadContext，都继承或实现了这两个接口ChannelHandlerContext 和 ChannelHandler ，它们互相指向, 构成一个类似于双向链表的容器
-
TailContext ：我的理解是它是整个链的最后，虽然它实现了ChannelInboundHandler，但是实现的方法都是空实现，我认为它针对Inbound没有实际上的作用(有点怪异)，查资料网上有说法，因为在最后，没有具体实现，说明是一种优雅的退出。
image.png
-
HeadContext ：我的理解是它是整个链的第一个，它对ChannelInboundHandler和ChannelOutboundHandler所有方法都有了实现
image.png
-
ChannelHandlerContext ：是ChannelPipeline 链中每一个handler 的上下文信息，负责调用对应的ChannelHandler，并指定下一个ChannelHandlerContext(我的理解)
-
ChannelHandler : 负责执行对应的handler，并回调context进行下一次调用
image.png
最后ChannelPipeline真正在哪加载的？
我们会看到上面摘取的部分Example源码中，有初始化ChannelPipeline，本以为此处就是加载处，但是后面看到ServerBootstrap.bind方法后，发现里面有个init方法，这里又再次重新加载了，我猜想是因为刚开始的Channel通道没有被绑定或注册到真正的Channel上，还需要进一步探讨。
image.png
2017-12-17 01:24
