服务器IO处理模型

背景

本文探讨的服务器模型主要指的是服务端对IO的处理模型。从不同的维度可以有不同的分类，本文主要从IO的阻塞与非阻塞，IO处理的单线程和多线程角度探讨服务器模型。
下面将对线程和阻塞的组合进行分析。

• 对于IO，可以分成阻塞IO和非阻塞IO两大类型。阻塞IO在做IO读写操作时会使当前线程进入阻塞状态，而非阻塞IO则不会进入阻塞状态。
• 对于线程，单线程情况下由一条线程负责所有客户端连接的IO操作，而多线程情况下则由若干线程共同处理所有客户端连接的IO操作。

单线程阻塞IO模型

单线程阻塞IO是最简单的一种服务器模型，几乎所有程序员刚开始接触时都从这个简单的模型开始。这种模型只能同时处理一个客户端访问，并且在IO操作上是阻塞的，线程会一直在等待，而不会做其他事情。对于多个客户端访问，必须要等到前一个客户端访问结束才能进行下一个访问的处理，请求一个一个排队，只提供一问一答服务。

这种模型的特点是服务器系统资源消耗较小，但并发能力低，容错能力差。

多线程阻塞IO模型

针对单线程阻塞IO模型的缺点，我们可以使用多线程对其进行改进，使之能并发地对多个客户端同时进行响应。多线程模型的核心就是利用多线程机制为每个客户端分配一个线程。

这种模型的IO操作也是阻塞的，因为每个线程执行到读取或写入操作时都将进入阻塞状态，直到读取客户端的数据或数据写入客户端后才解除阻塞状态。尽管IO操作阻塞，但这种模式比单线程处理的性能明显高了，它不用等到第一个请求处理完才处理第二个，而是并发地处理客户端请求，客户端连接与服务端处理线程的比例是1:1。

多线程阻塞IO模型的特点是支持多个客户端并发响应，处理能力得到大幅提高，有较大的并发量，但服务器系统资源消耗量较大，而且多线程之间会产生线程切换成本，同时拥有较复杂的结构。

单线程非阻塞IO模型

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

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

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

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

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

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

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

服务器端有多个客户端连接，应用层向内核请求读写事件列表。内核遍历所有套接字并生成对应的可读列表readList和可写列表writeList。readList标明了每个套接字是否可读，例如socket1的值为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模式，而对于客户端，出于方便及习惯，可使用阻塞模式的套接字进行通信。

参考资料：Tomcat内核设计剖析