打赏

Netty是如何处理新连接接入事件的?

 

更多技术分享可关注我

前言

前面的分析从Netty服务端启动过程入手,一路走到了Netty的心脏——NioEventLoop,又总结了Netty的异步API和设计原理,现在回到Netty服务端本身,看看服务端对客户端新连接接入的处理是怎么样的过程。

原文:​Netty是如何处理新连接接入事件的?

Java NIO处理新连接的编码模板

首先,对于新连接接入,从NIO层面有一个宏观的印象:

1、通过I/O多路复用器——Selector检测客户端新连接

对应到Netty,新连接通过服务端的NioServerSocketChannel(底层封装的JDK的ServerSocketChannel)绑定的I/O多路复用器(由NioEventLoop线程驱动)轮询OP_ACCEPT(=16)事件

2、轮询到新连接,就创建客户端的Channel

对应到Netty就是NioSocketChannel(底层封装JDK的SocketChannel)

3、为新连接分配绑定新的Selector

对应到Netty,就是通过线程选择器,从它的第二个线程池——worker线程池中挑选一个NIO线,在这个线程中去执行将JDK的SocketChannel注册到新的Selector的流程,将Netty封装的NioSocketChannel作为附加对象也绑定到该Selector

4、向客户端Channel绑定的Selector注册I/O读、或者写事件

对应到Netty,就是默认注册读事件,因为Netty的设计理念是读优先。以后本条Channel的读写事件就由worker线程池中的NIO线程管理

以上4步,其实就是对下面一段JDK NIO demo的抽象和封装,并解决了一些bug的过程,如下:

接下来的几篇文章会逐步拆解每个步骤,并学习Netty的设计思路。

简单复习Netty的多线程Reactor架构

前面分析过NioEventLoopGroup和线程池对应,NioEventLoop实例和NIO线程对应,一个EventLoop实例将由一个永远都不会改变的Thread驱动其内部的run方法(和Runnable的run不是一个)。

简单说,Netty服务端创建的boss和worker就是两个线程池,对于一个服务器的端口,bossGroup里只会启动一个NIO线程用来处理该端口上的客户端新连接的检测和接入流程。

具体的说,Netty会在服务端的Channel的pipeline上,默认创建一个新连接接入的handler,只用于服务端接入客户端新连接,而workerGroup里有多个NIO线程(默认2倍的CPU核数个),负责已建立的Channel上的读写事件的检测、注册或者处理,等操作。当boss线程池的那一个NIO线程检测到新连接后就可以稍做休息(或者继续检测处理新连接),此时worker线程池就开始忙碌,如下图所示:

细节回顾可以参考:Netty的线程调度模型分析(1)

下面开始总结,boss线程和worker线程池之间是如何配合的。

再看JDK的select方法

在总结之前,个人认为有必要先回顾JDK的select,必须正确理解I/O多路复用器——Selector上所谓的轮询一次,返回就绪的Channel数目的真正意义,即这个过程有一个前提是自从上次select后开始计算的。这样干巴巴的解释可能不太清楚,下面举个例子,比如有两个已经建立的Channel,分别是A和B,而且A和B分别注册到了一个Selector上,接着在该Selector调用select():

  • 第一次调用select(),发现只有A有I/O事件就绪,select会立即返回1,然后处理之

  • 第二次调用select(),发现另一个通道B也有I/O事件就绪,此时select()还是返回1——即是自上次select后开始计算的

还有一点注意:如果第一次轮询后,对A没有做任何操作,那么就有两个就绪的Channel。

另外还要知道,select返回后可通过其返回值判断有没有Channel就绪,如果有就绪的Channel,那么可以使用selectedKeys()方法拿到就绪的Channel及其一些属性。下面看selectedKeys()的使用:

Set<SelectionKey> selectedKeys = selector.selectedKeys();

当给Selector注册Channel时,调用的register()方法会返回一个SelectionKey对象,这个对象代表了注册到该Selector的Channel,可以遍历这个集合来访问就绪的通道。

以上,前面的线程调度模型都分析过,回忆这个图:

细节回顾可以参考:

Netty的线程调度模型分析(2)

Netty的线程调度模型分析(3)

Netty处理新连接接入事件的源码分析

前面文章总结了NioEventLoopGroup实例化时,如果外部没有配置,那么会默认创建一个线程执行器——ThreadPerTaskExcutor,一个NioEventLoop组成的数组(线程池),还有一个线程选择器——chooser。

又知道当实例化NioEventLoop并填充底层线程数组时,Netty会为每个NioEventLoop创建并绑定一个I/O多路复用器——Selector和一个异步任务队列——MPSCQ,接下来又总结了Netty的NioEventLoop线程启动的触发时机有两个:

  • 宏观上,服务端绑定端口时会触发boss线程池里的一个NIO线程启动,即用户代码调用bind方法。如果深入bind方法内部,那么会发现NIO线程第一次启动的精确时机是为JDK的ServerSocketChannel注册I/O多路复用器的时候——Netty会封装这个注册逻辑为一个异步task,使用NIO线程驱动,如果没有启动,那么就启动之,以后的Channel绑定端口的逻辑也会被封装为异步task,复用已经启动的这个NIO线程

  • 新连接接入时会触发worker线程池里的NIO线程启动。线程池的线程选择器会为新连接绑定一个worker里的NIO线程,第一次接入或者线程池的线程还没完全启动完毕,就会顺势启动

总之,Netty服务端启动后,服务端的Channel已经绑定到了boss线程池的NIO线程中,并不断检测是否有OP_ACCEPT事件发生,直到检测出有该事件发生就处理之,即boss线程池里的NioEventLoop线程只做了两件事:

1、轮询OP_ACCEPT事件

2、检测到OP_ACCEPT事件后就处理该事件,处理过程其实就是客户端Channel(新连接)接入的过程

下面继续回顾NioEventLoo线程的事件循环的核心方法——run,它在NIO线程启动时开始运行:

在这之前,先在run方法打断点:然后启动实验用的最小版Netty服务端的demo,之后分别在三个客户端使用telnet命令对其顺序发送3个请求,模拟客户端3个新连接接入的过程,下面进入run跟踪源码:

 

1、首先调用Netty封装的select方法,前面分析过当有客户端新连接接入,即代表已经触发了OP_ACCEPT事件,Selector的select方法会立即返回1,如下:

这里要理解JDK的select方法返回值到底是什么。select()方法会返回注册的interest的I/O事件已经就绪的那些通道的数目,抠字眼,首先得看是哪些Channel注册在了当前I/O多路复用器上,其次,看这些Channel上注册的interest的I/O事件是否就绪,如上代码的局部变量selectedKeys==1,但是我实验的客户端连接是3个,这里可能会有疑问,selectedKeys为何不是3呢?

因为当前绑定在boss线程上的I/O多路复用器只注册了服务端的Channel,即底层只有一个ServerSocketChannel,且当前注册的interest的I/O事件只有OP_ACCEPT,故无论多少个新连接接入,这里都只会返回1。

还有一个误区:不要认为Selector的select返回值是已准备就绪的Channel的总数,其实它返回的是从上一个select()调用后进入就绪状态的Channel的数量。

继续分析:轮询出有感兴趣的I/O事件就绪的Channel后,会break循环,回到外部的run方法,开始处理这个I/O事件,这里就是处理新连接的接入事件,核心方法之前也分析过,就是processSelectedKeys:

在详细的细节可以参考:

Netty的线程调度模型分析(7)

Netty的线程调度模型分析(8)

这个方法有两个变体,前面文章也分析过原因,我选择有代表性的processSelectedKeysOptimized,看里面的processSelectedKey(key,channel)方法,这才真正到了Netty处理I/O事件的方法入口,如下:

 如下是processSelectedKey方法的实现:

首先看黄色1处,取出ServerSocketChannel的unsafe对象,前面也总结过,Netty封装的Channel的底层都会有一个Unsafe对象与之绑定,Unsafe是个内部接口,聚合在Channel接口内部,作用是协助Channel进行网络I/O的操作,因为它的设计初衷就是Channel的内部辅助类,不应该被Netty的使用者调用,所以被命名为Unsafe,而不是说这个类的API都是不安全的。

继续执行到黄色2处,会判断当前Channel是否打开,其实就是判断的ServerSocketChannel。一切顺利继续执行黄色3处,看到了熟悉的NIO API,下面专门看黄色3处后面的一堆代码:

在黄色3处,k内部的readyOps集合是该Channel已经准备就绪的I/O操作的集合,OP_ACCEPT这个宏是16,所以这里的readyOps变量为16。 

接着马上会执行到黄色4处的if判断逻辑,由于readyOps为16,这里通过判断,进入if内部,执行黄色5处的代码。该处逻辑是一个read操作,很好理解。当NioEventLoop的run方法里轮询到ServerSocketChannel的accept事件后,服务端第一步就是对其执行读操作,这是很自然的想法。因为这是服务端,所以下面会进入到NioMessageUnsafe实例的read方法:

在黄色1处,首先保证是NioEventLoop线程在执行,如果是外部线程执行的,那么无效。接下来,会获取服务端Channel的Config和默认创建的服务端Channel的pipeline。在黄色2处有一个RecvByteBufAllocator.Handle allocHandle变量,它获取了RecvByteBuf分配器Handle,顾名思义就是设置接收的缓冲区大小,简单说是通过二分算法获取一个不会浪费空间,但是又足够大小的缓冲区,是一种性能优化的策略,以后分析Netty内存图像时在深入。

接着在黄色2处的下一行是一个重置配置的方法,目的是重置已累积的所有计数器,并为下一个读取循环读取多少消息/字节数据提供建议。Netty默认一次读取16个新连接,如下:

然后继续看NioMessageUnsafe实例的read方法,在黄色3处,进入一个do-while循环:

 

首先调用doReadMessages方法,在do—while循环中读取一个个的客户端新连接,并将读取到的新连接用readBuf这个集合存储,readBuf就是NioMessageUnsafe类内部的一个普通的ArrayList。

下面进入doReadMessages方法,如下该方法内部逻辑似曾相识。

首先,在黄色1处封装了JDK的NIO API,即获取客户端的socket——NIO对应的是SocketChannel,完成该操作意味着TCP/IP协议栈完成了TCP的三次握手,TCP的逻辑链路正式建立,然后,在黄色2处,Netty将客户端Channel封装为自己的客户端channel——NioSocketChannel。因为这里明确了是服务端在处理accept事件,故不需要反射创建NioSocketChannel,直接实例化即可,后续在详细分析Netty的客户端channel创建过程。最后,封装的Channel保存到readBuf这个ArrayList中,doReadMessages方法返回1。 

回到上层的do-while循环:

doReadMessages返回的localRead==1,说明本次读取新连接成功,do-while的一次循环读新连接完毕,会继续读下一个新连接,直到全部读完,或者达到阈值。也就是说Netty在读取新连接时也权衡了性能,如果连接太多,那么Netty不会一直卡在这里处理,它默认do-while循环处理16个,这个逻辑在黄色5处的判断条件里,超过阈值就退出do-while。

下面看黄色5处的判断逻辑——即continueReading()方法,简单看下:

Netty设计理念是读优先,会给服务端Channel自动注册OP_READ事件——也就是isAutoRead()方法会返回true,那个maxMessagePerRead默认配置的是16,即每一次集中处理accept事件时,最多读取的连接数为16个,是权衡了性能而设计的,这个可以由用户配置。

继续回看NioMessageUnsafe实例的read方法,如果有新连接,那么继续do-while循环,直到发生异常,或者读取的新连接数量达到了阈值,或者已经没有新连接可读,doReadMessages返回0,退出do-while循环。这里说明一下,正常情况doReadMessages里的accept一定不会阻塞,因为只有当Channel里有就绪的I/O事件,换句话说,有数据可以读,才会进入accept环节,本质是因为Netty服务端为NIO模型配置的是非阻塞I/O,即Netty会自动对各个Channel有如下的配置:

而且,如果服务端Channel有就绪的I/O事件,那么accept()一定会返回客户端Channel,除非实例化Netty的客户端Channel——NioSocketChannel时出现异常。

如果doReadMessages返回0,那么就会break出do-while循环,接下来大动脉——Netty的pipeline就该干活了,如下NioMessageUnsafe实例的read方法的后面的源码:

在黄色6处,遍历保存客户端新Channel的集合——readBuf,然后将每个新连接传播出去——调用pipeline.fireChannelRead(),将每条新连接沿着服务端Channel的pipeline传递,交给Channel后续的入站handler,而黄色7处,会传播一个读操作完成的事件——fireChannelReadComplete();后续会逐渐的拆解并详细分析pipeline的设计,这里知道即可。

至此,Netty服务端检测处理客户端新连接的过程分析完毕。

做个小结

1、权衡性能,NIO线程一次处理的新连接不能太多,Netty默认是一次最多处理16个

2、Netty的pipeline机制和读取新连接后的衔接过程——触发和传递

3、Selector的select返回值的理解

4、深刻理解同步非阻塞,即NIO模式下,accept方法为什么不会阻塞

posted @ 2020-04-17 23:38  dashuai的博客  阅读(3207)  评论(0编辑  收藏  举报
Flag Counter欢迎关注微信公众号