Netty源码分析--处理客户端接入请求(八)

           这一节我们来一起看下,一个客户端接入进来是什么情况。首先我们根据之前的分析,先启动服务端,然后打一个断点。

    这个断点打在哪里呢?就是NioEventLoop上的select方法上。

    Netty源码分析--处理客户端接入请求(八)_第1张图片

   然后我们启动一个客户端。

   

  然后我们debug看到,selectedKey的数量 = 1,说明有accept或者读写等事件发生。

  接下就会进 processSelectedKeys() 

Netty源码分析--处理客户端接入请求(八)_第2张图片

Netty源码分析--处理客户端接入请求(八)_第3张图片

我们上一节讲到,这里的attach就是NioServerSocketChannel, 我们进入 processSelectedKey() 方法

Netty源码分析--处理客户端接入请求(八)_第4张图片

     重点来了,这里对各种事件进行分发,debug看我们现在是16,也就是说是accept事件。

     继续跟进去F5进去

     Netty源码分析--处理客户端接入请求(八)_第5张图片

    发现进入到了AbstractNioMessageChannel的read方法。这里进入的是 AbstractNioMessageChannel !!!;

    为了加深印象,我们先暂停,重新跑一个读事件

   Netty源码分析--处理客户端接入请求(八)_第6张图片

  发现当前的selectKey = 1,也就是读事件

 

 F5 进入

 Netty源码分析--处理客户端接入请求(八)_第7张图片

  发现,读事件进入到AbstractNioByteChannel中,

  那么也就是accept进入  AbstractNioMessageChannel , 而 read 进入AbstractNioByteChannel 中。

  好了,我们回过头来继续看 AbstractNioMessageChannel 中的read 方法。

  Netty源码分析--处理客户端接入请求(八)_第8张图片

 关于这个分配器,这里我先不看,待后面分析内存模型的时候再说。我们直接看下面的代码:

 Netty源码分析--处理客户端接入请求(八)_第9张图片

 我们发现这个是一个循环,不断的调用doReadMessages方法,并且传入了一个readBuf,而且这个readBuf是一个ArrayList, 那这里我们猜测可能是把读取到的客户端放到List集合中保存,然后再循环处理客户端连接。

 进入doReadMessage方法一探究竟。

通过工具类调用 NioServerSocketChannel 内部封装的 serverSocketChannel 的 accept 方法,获取一个SocketChannel, 如果大家还记得我第一篇讲NIO的地方 Netty源码分析--NIO(一),这里应该会有印象,我这里贴出来:

Netty源码分析--处理客户端接入请求(八)_第10张图片

 这里就是获取到了客户端的socketChannel

 Netty源码分析--处理客户端接入请求(八)_第11张图片

 然后这里将SocketChannel封装成了一个NioSocketChannel,然后添加到了readBuf这个ArrayList中存储。

 

封装这里,这里不想多说了,跟创建NioServerSocketChannel类似,大家可以去回顾一下 Netty源码分析--创建Channel(三)。 

 Netty源码分析--处理客户端接入请求(八)_第12张图片

 继续往下看,这里就是循环readBuf,链式执行 管道中的 handler 的 ChannelRead 方法。

 根据前面几篇的分析,我们知道 , pipeline 里面又 4 个 handler ,分别是 Head,LoggingHandler,ServerBootstrapAcceptor,Tail,链式调用其中的 ChannelRead  方法,这里我们着重看  ServerBootstrapAcceptor 中个的 ChannelRead  方法。

Netty源码分析--处理客户端接入请求(八)_第13张图片

Netty源码分析--处理客户端接入请求(八)_第14张图片

 这里为刚刚的客户端channel 添加了handler,设置了options和childAttrs,注意这里的addLast方法,并没有调用initChannel方法,具体这里添加了什么,我前面几篇有提及,大家可以再回顾一下。

Netty源码分析--处理客户端接入请求(八)_第15张图片

  Netty源码分析--处理客户端接入请求(八)_第16张图片

   接下来这里呢,就是把客户端channel注册到多路复用器上,跟服务端channel注册的流程是一样的。大家可以去看

   Netty源码分析--Channel注册(上)(五)

   Netty源码分析--Channel注册(中)(六)

   Netty源码分析--Channel注册&绑定端口(下)(七)

  我们直接说重点:

   Netty源码分析--处理客户端接入请求(八)_第17张图片

   注册完成之后,就进入到了 pipeline.invokeHandlerAddedIfNeeded() 方法,我们跟下这个代码。

   Netty源码分析--处理客户端接入请求(八)_第18张图片

   跟下去我们会进入上图这个execute()方法,如上图,我们看下  ctx

   那么链式结构也就是 HeadContext -> NettyServer【ChannelInitializer】(我的启动类) -> TailContext

   Netty源码分析--处理客户端接入请求(八)_第19张图片

  不断的跟下去,我们发现其实就是去调用当初我们在NettyServer中的initChannel。

  Netty源码分析--处理客户端接入请求(八)_第20张图片

  那么也就是说,这里才是真正往pipeline中添加handler的过程!!!

  神奇的是,后面还有一个remove方法。

  Netty源码分析--处理客户端接入请求(八)_第21张图片

  那么这个是啥意思呢?我们再来看下ctx的链式结构

   Netty源码分析--处理客户端接入请求(八)_第22张图片

   

  也就是说变成了 HeadContext - > NettyServer ->  IdleStateHandler ...等 -> TailContext

  大家发现了吗? NettyServer 还在, 也就是  ChannelInitializer 这个handler 还在链上,但是它的作用已经结束了,没错,这里删除的就是它。

  Netty源码分析--处理客户端接入请求(八)_第23张图片

  怎么删的就不说了,无非就是把 ChannelInitializer 两段的链表直接连接起来,把 ChannelInitializer  剔除就可以了。

  接下来就是  pipeline.fireChannelRegistered(); 和 pipeline.fireChannelActive();

  就是在所有的handler中链式调用channelRegister 和 channelActive方法。

  总结一下:ServerBootstrapAcceptor 才是那个负责接收客户端连接,并且将其注册到多路复用器上的核心类

  那么到这里,客户端的接入就完成了,下一篇我们来看,客户端的读写过程以及Netty的内存模型是什么样子的。

  

你可能感兴趣的:(Netty源码分析--处理客户端接入请求(八))