Netty学习之旅------源码分析ChannelPipeline实现原理

2401_84048290

于 2024-04-04 05:40:52 发布

阅读量611

点赞数 20

分类专栏：程序员文章标签：学习网络网络协议

本文链接：https://blog.csdn.net/2401_84048290/article/details/137363925

版权

程序员专栏收录该内容

459 篇文章 0 订阅

订阅专栏

接下来进入到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 来实现链表，而是在其自身就是一个链表结构，链表的节点是AbstractChannelHandlerContext，里面有next,与perv分别指向下一个或上一个节点。在DefaultChannelHanderPipeline中持有tail与head引用。

以下实例方法来自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部门的源码分析，编码解码的核心原理。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。