2021-05-05 16:51  阅读(126)
文章分类:Netty 学习之旅 文章标签:NettyNetty 学习
©  原文作者:中间件兴趣圈 原文地址:https://blog.csdn.net/prestigeding/article/details/53977445

本文主要从如下方面展示:

  • Netty bind源码分析
  • ChannelPipline链式请求源码分析

1、Netty ServerBootstrap bind源码跟踪

本文将重点分析Netty服务端绑定端口流程。

1.1 入口程序

202105051651354461.png

1.2 AbstractBootstarp的doBind方法

202105051651356522.png

202105051651359083.png

  • 初始化一个通道,并注册,如果注册失败,直接返回。
  • 如果初始化并立即注册成功,执行doBind0方法,进行绑定
  • 如果未立即注册成功,则添加监听事件,等初始化并注册成功后,执行doBind0方法,这里是Netty对jdk Future模式进行的扩展,引入事件机制

1.2.1 AbstractBoostart initAndRegister方法

202105051651359874.png

202105051651361565.png

初始化一个Channel类实例,此处返回的是io.netty.channel.socket.nio.NioServerSocketChannel实例,然后调用init方法初始Channel,AbstractBootstrap中的init为抽象方法,有具体子类实现。Channel初始化后,就是将该通道注册到Selector上。

1.2.1.1 ServerBootstrap init方法

202105051651362946.png

202105051651365207.png

1.2.1.2 group().register 方法

根据Netty线程模型,group()返回的是EventLoopGroup,然后Netty会从该EventLoopGroup中获取下一个EventLoop来执行。由于程序入口使用的是NioServerSocketChannel,故本例最终会使用NioEventLoop来作为事件处理器来服务,这里的register方法,其实现在NioEventLoop的父类SingleThreadEventLoop中。

202105051651367168.png

有关Channel的IO类操作,最终都会转发给Unsafe类去执行,直接进入到AbstractUnsafe中

202105051651368439.png

2021050516513706910.png

register方法,确保绑定操作在通道所关联的事件处理器(EventLoop)中执行,真正注册方法为

2021050516513723011.png

接下来进入到doRegister,该类有具体的通道子类实现,这里我们关注的是NioServerSocketChannel类,在该类的父类AbstractNioChannel中实现:

2021050516513745812.png

完成Channel的注册外,需要调用管道的pipline.fireChannelRegistered,跟踪进去,最终将执行DefaultChannelHandlerInvoker的invokeChannelRegistered方法。该方法会执行ChannelInitializer的init

2021050516513763913.png

ChannelInitializer的channelRegistered()方法被执行,这里正是代码中初始化业务handler的地方了。

2021050516513777914.png

2021050516513796315.png

总结与问题引出:

1、以Nio为例,绑定操作,主要完成Channel到Selector的注册,Channel绑定监听端口。

2、再提线程模型,与Channel通道的操作,无论是绑定,还是读,或写的执行,都是放在与Channel绑定的

3、Netty的ChannelPipeline的核心原理或思想是基于处理链条的拦截机制,就像上文的sc.pipeline().addLast( ChannelHander ),将各个逻辑处理单元(Handler)随链条一个一处理,第一个节点为HeaderHandler,尾部为TailHandler。

2、ChannelPipeline相关源码分析

2.1 ChannelPipeline类图设计

2021050516513809516.png

设计理念: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,具体如下图:

2021050516513849317.png
为了更好的理解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部门的源码分析,编码解码的核心原理。


来源:https://blog.csdn.net/prestigeding/article/details/53977445

点赞(0)
版权归原创作者所有,任何形式转载请联系作者; Java 技术驿站 >> 源码分析ChannelPipeline实现原理
上一篇
图说Netty线程模型
下一篇
源码分析Netty解码编码器实现原理