前言的前言 

服务器模型涉及到线程模式和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操作上是阻塞的，线程会一直在等待，而不会做其他事情。对于多个客户端访问，必须要等到前一个客户端访问结束才能进行下一个访问的处理，请求一个一个排队，只提供一问一答服务。

首先，服务器必须初始化一个套接字服务器，并绑定某个端口号并使之监听客户端的访问。接着，客户端1调用服务器的服务，服务器接收到请求后对其进行处理，处理完后写数据回客户端1，整个过程都是在一个线程里面完成的。最后，处理客户端2的请求并写数据回客户端2，期间就算客户端2在服务器处理完客户端1之前就进行请求，也要等服务器对客户端1响应完后才会对客户端2进行响应处理。

这种模型的特点在于单线程和阻塞I/O。单线程即服务器端只有一个线程处理客户端的所有请求，客户端连接与服务器端的处理线程比是n:1，它无法同时处理多个连接，只能串行处理连接。而阻塞I/O是指服务器在读写数据时是阻塞的，读取客户端数据时要等待客户端发送数据并且把操作系统内核复制到用户进程中，这时才解除阻塞状态。写数据回客户端时要等待用户进程将数据写入内核并发送到客户端后才解除阻塞状态。这种阻塞给网络编程带来了一个问题，服务器必须要等到客户端成功接收才能继续往下处理另外一个客户端的请求，在此期间线程将无法响应任何客户端请求。

该模型的特点：它是最简单的服务器模型，整个运行过程都只有一个线程，只能支持同时处理一个客户端的请求（如果有多个客户端访问，就必须排队等待），服务器系统资源消耗较小，但并发能力低，容错能力差。

多线程阻塞I/O模型 

针对单线程阻塞I/O模型的缺点，我们可以使用多线程对其进行改进，使之能并发地对多个客户端同时进行响应。多线程模型的核心就是利用多线程机制为每个客户端分配一个线程。服务器端开始监听客户端的访问，假如有两个客户端发送请求过来，服务器端在接收到客户端请求后分别创建两个线程对它们进行处理，每条线程负责一个客户端连接，直到响应完成。期间两个线程并发地为各自对应的客户端处理请求，包括读取客户端数据、处理客户端数据、写数据回客户端等操作。

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

多线程阻塞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模式，而对于客户端，出于方便及习惯，可使用阻塞模式的套接字进行通信。

多线程非阻塞I/O模型 

单线程非阻塞I/O模型已经大大提高了机器的效率，而在多核的机器上可以通过多线程继续提高机器效率。最朴实、最自然的做法就是将客户端连接按组分配给若干线程，每个线程负责处理对应组内的连接。如图所示，有4个客户端访问服务器，服务器将套接字1和套接字2交由线程1管理，而线程2则管理套接字3和套接字4，通过事件检测及非阻塞读写就可以让每个线程都能高效处理。

最经典的多线程非阻塞I/O模型方式是Reactor模式。首先看单线程下的Reactor，Reactor将服务器端的整个处理过程分成若干个事件，例如分为接收事件、读事件、写事件、执行事件等。Reactor通过事件检测机制将这些事件分发给不同处理器去处理。如图所示，若干客户端连接访问服务器端，Reactor负责检测各种事件并分发到处理器，这些处理器包括接收连接的accept处理器、读数据的read处理器、写数据的write处理器以及执行逻辑的process处理器。在整个过程中只要有待处理的事件存在，即可以让Reactor线程不断往下执行，而不会阻塞在某处，所以处理效率很高。

基于单线程Reactor模型，根据实际使用场景，把它改进成多线程模式。常见的有两种方式：一种是在耗时的process处理器中引入多线程，如使用线程池；另一种是直接使用多个Reactor实例，每个Reactor实例对应一个线程。

Reactor模式的一种改进方式如图所示。其整体结构基本上与单线程的Reactor类似，只是引入了一个线程池。由于对连接的接收、对数据的读取和对数据的写入等操作基本上都耗时较少，因此把它们都放到Reactor线程中处理。然而，对于逻辑处理可能比较耗时的工作，可以在process处理器中引入线程池，process处理器自己不执行任务，而是交给线程池，从而在Reactor线程中避免了耗时的操作。将耗时的操作转移到线程池中后，尽管Reactor只有一个线程，它也能保证Reactor的高效。

Reactor模式的另一种改进方式如图所示。其中有多个Reactor实例，每个Reactor实例对应一个线程。因为接收事件是相对于服务器端而言的，所以客户端的连接接收工作统一由一个accept处理器负责，accept处理器会将接收的客户端连接均匀分配给所有Reactor实例，每个Reactor实例负责处理分配到该Reactor上的客户端连接，包括连接的读数据、写数据和逻辑处理。这就是多Reactor实例的原理。

多线程非阻塞I/O模式让服务器端处理能力得到很大提高，它充分利用机器的CPU，适合用于处理高并发的场景，但它也让程序更复杂，更容易出现问题。