服务器模型——从单线程阻塞到多线程非阻塞（中）

前言的前言

服务器模型涉及到线程模式和IO模式，搞清楚这些就能针对各种场景有的放矢。该系列分成三部分：

* 单线程/多线程阻塞I/O模型

* 单线程非阻塞I/O模型

* 多线程非阻塞I/O模型，Reactor及其改进

前言

这里探讨的服务器模型主要指的是服务器端对I/O的处理模型。从不同维度可以有不同的分类，这里从I/O的阻塞与非阻塞、I/O处理的单线程与多线程角度探讨服务器模型。

对于I/O，可以分成阻塞I/O与非阻塞I/O两大类型。阻塞I/O在做I/O读写操作时会使当前线程进入阻塞状态，而非阻塞I/O则不进入阻塞状态。

对于线程，单线程情况下由一条线程负责所有客户端连接的I/O操作，而多线程情况下则由若干线程共同处理所有客户端连接的I/O操作。

单线程非阻塞I/O模型

多线程阻塞I/O模型通过引入多线程确实提高了服务器端的并发处理能力，但每个连接都需要一个线程负责I/O操作。当连接数量较多时可能导致机器线程数量太多，而这些线程大多数时间却处于等待状态，造成极大的资源浪费。鉴于多线程阻塞I/O模型的缺点，有没有可能用一个线程就可以维护多个客户端连接并且不会阻塞在读写操作呢？下面介绍单线程非阻塞I/O模型。

单线程非阻塞I/O模型最重要的一个特点是，在调用读取或写入接口后立即返回，而不会进入阻塞状态。在探讨单线程非阻塞I/O模型前必须要先了解非阻塞情况下套接字事件的检测机制，因为对于单线程非阻塞模型最重要的事情是检测哪些连接有感兴趣的事件发生。一般会有如下三种检测方式。

应用程序遍历套接字的事件检测

当多个客户端向服务器请求时，服务器端会保存一个套接字连接列表中，应用层线程对套接字列表轮询尝试读取或写入。对于读取操作，如果成功读取到若干数据，则对读取到的数据进行处理；如果读取失败，则下一个循环再继续尝试。对于写入操作，先尝试将数据写入指定的某个套接字，写入失败则下一个循环再继续尝试。

这样看来，不管有多少个套接字连接，它们都可以被一个线程管理，一个线程负责遍历这些套接字列表，不断地尝试读取或写入数据。这很好地利用了阻塞的时间，处理能力得到提升。但这种模型需要在应用程序中遍历所有的套接字列表，同时需要处理数据的拼接，连接空闲时可能也会占用较多CPU资源，不适合实际使用。对此改进的方法是使用事件驱动的非阻塞方式。

内核遍历套接字的事件检测

这种方式将套接字的遍历工作交给了操作系统内核，把对套接字遍历的结果组织成一系列的事件列表并返回应用层处理。对于应用层，它们需要处理的对象就是这些事件，这就是其中一种事件驱动的非阻塞方式的实现。

服务器端有多个客户端连接，应用层向内核请求读写事件列表。内核遍历所有套接字并生成对应的可读列表readList和可写列表writeList。readList标明了每个套接字是否可读，例如套接字1的值为1，表示可读，socket2的值为0，表示不可读。writeList则标明了每个套接字是否可写。应用层遍历读写事件列表readList和writeList，做相应的读写操作。

内核遍历套接字时已经不用在应用层对所有套接字进行遍历，将遍历工作下移到内核层，这种方式有助于提高检测效率。然而，它需要将所有连接的可读事件列表和可写事件列表传到应用层，假如套接字连接数量变大，列表从内核复制到应用层也是不小的开销。另外，当活跃连接较少时，内核与应用层之间存在很多无效的数据副本，因为它将活跃和不活跃的连接状态都复制到应用层中。

内核基于回调的事件检测

通过遍历的方式检测套接字是否可读可写是一种效率比较低的方式，不管是在应用层中遍历还是在内核中遍历。所以需要另外一种机制来优化遍历的方式，那就是回调函数。内核中的套接字都对应一个回调函数，当客户端往套接字发送数据时，内核从网卡接收数据后就会调用回调函数，在回调函数中维护事件列表，应用层获取此事件列表即可得到所有感兴趣的事件。

内核基于回调的事件检测方式有两种。第一种是用可读列表readList和可写列表writeList标记读写事件，套接字的数量与readList和writeList两个列表的长度一样，readList第一个元素标为1则表示套接字1可读，同理，writeList第二个元素标为1则表示套接字2可写。如图所示，多个客户端连接服务器端，当客户端发送数据过来时，内核从网卡复制数据成功后调用回调函数将readList第一个元素置为1，应用层发送请求读、写事件列表，返回内核包含了事件标识的readList和writeList事件列表，进而分表遍历读事件列表readList和写事件列表writeList，对置为1的元素对应的套接字进行读或写操作。这样就避免了遍历套接字的操作，但仍然有大量无用的数据（状态为0的元素）从内核复制到应用层中。于是就有了第二种事件检测方式。

内核基于回调的事件检测方式二如图所示。服务器端有多个客户端套接字连接。首先，应用层告诉内核每个套接字感兴趣的事件。接着，当客户端发送数据过来时，对应会有一个回调函数，内核从网卡复制数据成功后即调回调函数将套接字1作为可读事件event1加入到事件列表。同样地，内核发现网卡可写时就将套接字2作为可写事件event2添加到事件列表中。最后，应用层向内核请求读、写事件列表，内核将包含了event1和event2的事件列表返回应用层，应用层通过遍历事件列表得知套接字1有数据待读取，于是进行读操作，而套接字2则可以写入数据。

上面两种方式由操作系统内核维护客户端的所有连接并通过回调函数不断更新事件列表，而应用层线程只要遍历这些事件列表即可知道可读取或可写入的连接，进而对这些连接进行读写操作，极大提高了检测效率，自然处理能力也更强。

对于Java来说，非阻塞I/O的实现完全是基于操作系统内核的非阻塞I/O，它将操作系统的非阻塞I/O的差异屏蔽并提供统一的API，让我们不必关心操作系统。JDK会帮我们选择非阻塞I/O的实现方式，例如对于Linux系统，在支持epoll的情况下JDK会优先选择用epoll实现Java的非阻塞I/O。这种非阻塞方式的事件检测机制就是效率最高的“内核基于回调的事件检测”中的第二种方式。

在了解了非阻塞模式下的事件检测方式后，重新回到对单线程非阻塞I/O模型的讨论。虽然只有一个线程，但是它通过把非阻塞读写操作与上面几种检测机制配合就可以实现对多个连接的及时处理，而不会因为某个连接的阻塞操作导致其他连接无法处理。在客户端连接大多数都保持活跃的情况下，这个线程会一直循环处理这些连接，它很好地利用了阻塞的时间，大大提高了这个线程的执行效率。

单线程非阻塞I/O模型的主要优势体现在对多个连接的管理，一般在同时需要处理多个连接的发场景中会使用非阻塞NIO模式，此模型下只通过一个线程去维护和处理连接，这样大大提高了机器的效率。一般服务器端才会使用NIO模式，而对于客户端，出于方便及习惯，可使用阻塞模式的套接字进行通信。