主要由I/O单元，逻辑单元和网络存储单元组成，其中每个单元之间通过请求队列进行通信，从而协同完成任务。

其中I/O单元用于处理客户端连接，读写网络数据；逻辑单元用于处理业务逻辑的线程；网络存储单元指本地数据库和文件等。

（图片出处：两猿社）

2.1 五种I/O模型

首先明确的是，整个过程可以分为2个部分：等待数据就绪 和 读取数据，不同I/O模型的不同之处，主要是在于对这两个部分的处理上。在《UNIX网络编程》中，总共归纳了5中IO模型：

阻塞I/O

调用者调用了某个函数，等待这个函数返回，期间什么也不做，直到等待数据就绪后，再等待数据拷贝，直至最后成功后，返回成功。显而易见，这种模型下的性能其实是不理想的，因为阻塞期间任何事情都做不了。

非阻塞IO

非阻塞I/O的非阻塞其实仅仅只是根据第一部门——等待数据来的，recvfrom操作会不停的忙轮询内核是否准备好数据，直到数据已经准备就绪返回成功为止。但是对于第二部门来说，在拷贝过程中，进程依然是处于阻塞状态的。

事实上，在使用非阻塞I/O下，性能对于阻塞I/O并没有提升，相反，由于程序会不停的通过忙轮询来访问内核是否已准备好数据，CPU的用量还会增加。

I/O 多路复用

无论是阻塞I0还是非阻塞I0,用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案:

• 如果调用recvfrom时,恰好没有数据，阻塞|0会使进程阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。
• 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

文件描述符( File Descriptor) :简称FD,是一个从0开始递增的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件,例如常规文件、视频、硬件设备等,当然也包括网络套接字(Socket) 。

I/O多路复用则是利用单个线程来同时监听多个FD,并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

在这种模式下，每次select系统调用时，一次性会传入多个FD，只要其中有任何一个已经准备就绪了，那就可以立刻对其做处理。

在这个基本的思想下，LINUX中封装了3种方式：

• select
• poll
• epoll

select

select是linux中最早的I/O多路复用的实现方案。

注意源码中一个细节，保存fd的fd_set结构体中，用于存放fd的数组的类型是 __fd_mask 也就是上述定义的 long int，所以每一个元素占4个字节。而数组中总长度为32，也就是说数组总共占128个字节，也即是1024 个比特位。而保存fd时，使用每一个比特位来保存一个fd，那么在select中，最多可以监听1024个fd。在select中使用比特位去保存fd ，极大的节约了内存空间。

但是每一次调用select都会传递所有长度的fd，并且内核中并不知道具体是监听了哪个fd，所以需要通过遍历的办法来查看是否有就绪的fd，当任意一个fd可读时，内核就将结果写入fd中——将原本为1但未就绪的比特位变为0，并一并返回所有就绪fd的个数。这样，在用户空间中再次通过遍历的方式去找到就绪的fd，并读取其中的数据。

• 虽然select模型极大的节省了内存空间，但是这种设计没法直观的显示出具体就绪的fd，也就是说，每执行一次都存在2次用户态和内核态的切换 和 2次内存的拷贝，并且需要遍历两次fd的集合，所以select性能对比之后的模型并不是很好。并且由于这种比特位的设计，监听的最大数量不能超过1024。

poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下:

对比与select，poll放弃了select比特位的设计，而是采用了直接保存fd对应编号的方法，在事件类型的处理上也放弃了采用3个不同的集合来分别保存的设计，而是将要监听事件的类型 和 实际发生事件的类型 一并与fd编号保存在了pollfd结构体中，并且存放fd的数组大小是可以通过nfds自定义的，理论上是可以无上限的。

但是无论是调用poll后传入fd集合到内核空间后，还是在用户空间得到返回已就绪的fd集合后，与select一样，都需要再通过遍历的方式去找到具体已就绪的fd。监听的fd越多，每次遍历需要耗时也就越久，性能反而会下降，所以对比select，性能并没有很大的提升。

epoll

epoll模式是对select和poll的改进，当epoll创建实例时，会再内核空间中建立2个数据结构：一个红黑树rb_root，一个链表list_head。

通过epoll_ctl来操作这两个数据结构，红黑树用于保存每一个需要监听的fd，并且对于每一个fd都设置一个回调（callback）函数，当这个函数触发时就会把对应的fd加入到rdlist这个就绪队列中。

通过epoll_wait操作，来接收已就绪的并存放于relist中的fd，并拷贝到用户空间中，注意与前两种模型的巨大区别——epoll仅仅拷贝了已就绪的fd，并不会将所有fd都拷贝到用户空间再进行遍历

相比于前两种模式，epoll模式解决了：

• select和poll每一次都需要拷贝fd集合到内核空间，在执行完毕后，再将fd集合拷贝到用户空间；而epoll通过将select和poll功能拆分为epoll_ctl 和 epoll_wait，避免了这种不必要的拷贝，仅拷贝已就绪的fd
• 在select和poll中，每次成功返回 或 传入fd集合之后，都需要通过遍历来找到已就绪的fd；而epoll则通过建立两个数据结构：红黑树rb_root，链表list_head来避免遍历，做到了高效。
• 在select中fd的上限为1024，在poll中虽然理论上可以支持无限数量的fd，但是由于链表的需要遍历的特性，当fd数量增多时会极大的降低性能，它们都无法满足超大数量的；而对于epoll，采用红黑树来保存fd，无论是增删改查，操作的时间复杂度都是O(logN)。

epoll的ET和LT模式

当FD有数据可读时，我们调用epoll_wait就可以得到通知。但是事件通知的模式有两种:

• LevelTriggered：简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epol的默认模式。
• EdgeTriggered：简称ET。当FD有数据可读时，只会被通知一次,不管数据是否处理完成。

由于LT模式会重复通知，直到数据处理完成，所以LT模式可能对性能存在一定影响，并且LT模式会出现惊群的现象。那么如何解决ET模式下，数据读取不完全的问题呢。以下介绍2种方法：

0. 调用epoll_ctl修改fd 的状态，将未处理完成的fd再修改为待处理的状态，那么当下一次ET模式下的epoll_wait调用时，又会将上次未处理完的fd加入rdlist。但是这种类似于LT模式的办法，反复操作rb_root中的fd对性能是有影响的。
1. 在调用epoll_wait后，使用循环的方法在rdlist中读取数据，直到读取完毕。但是这种模式不能采取阻塞I/O的模式实现，因为当数据读取完毕后，会阻塞整个程序。而应采用非阻塞I/O的模式，当没有可读取的数据后，返回一个false值来跳出循环。

信号驱动IO

信号驱动I0是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

这里与非阻塞I/O比较类似，但是对于其他业务来说，进程并不阻塞，而是通过注册sigio信号处理函数来采用信号的方式通知进程数据已准备好。

但是，当有大量I0操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出。而且内核空间与用户空间的频繁信号交互性能也较低。

异步I/O

linux中，可以调用aio_read函数告诉内核描述字缓冲区指针和缓冲区的大小、文件偏移及通知的方式，然后立即返回，当内核将数据拷贝到缓冲区后，再通知应用程序。异步I0的整个过程都是非阻塞的，用户进程调用完异步API后就可以去做其它事情，内核等待数据就绪并拷贝到用户空 间后才会递交信号，通知用户进程。

但是在高并发情况下，由于异步I/O不会有任何阻塞，用户应用会大量的调用aio_read函数，但是I/O读写效率并不高，所以导致大量的I/O读写任务累积在内核中，消耗大量的内存最终导致系统崩溃，所以在使用异步I/O时，需要手动的控制调用次数避免大量调用，所以实现上比较繁琐。

2.2 事件处理模式

（该部分转载自 小林coding）

Reactor

单 Reactor 单进程 / 线程

一般来说，C 语言实现的是「单 Reactor 单进程」的方案，因为 C 语编写完的程序，运行后就是一个独立的进程，不需要在进程中再创建线程。

而 Java 语言实现的是「单 Reactor 单线程」的方案，因为 Java 程序是跑在 Java 虚拟机这个进程上面的，虚拟机中有很多线程，我们写的 Java 程序只是其中的一个线程而已。

我们来看看「单 Reactor 单进程」的方案示意图：

可以看到进程里有 Reactor、Acceptor、Handler 这三个对象：

• Reactor 对象的作用是监听和分发事件；
• Acceptor 对象的作用是获取连接；
• Handler 对象的作用是处理业务；

对象里的 select、accept、read、send 是系统调用函数，dispatch 和 「业务处理」是需要完成的操作，其中 dispatch 是分发事件操作。

接下来，介绍下「单 Reactor 单进程」这个方案：

• Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
• 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
• 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；
• Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。

单 Reactor 单进程的方案因为全部工作都在同一个进程内完成，所以实现起来比较简单，不需要考虑进程间通信，也不用担心多进程竞争。

但是，这种方案存在 2 个缺点：

• 第一个缺点，因为只有一个进程，无法充分利用 多核 CPU 的性能；
• 第二个缺点，Handler 对象在业务处理时，整个进程是无法处理其他连接的事件的，如果业务处理耗时比较长，那么就造成响应的延迟；

所以，单 Reactor 单进程的方案不适用计算机密集型的场景，只适用于业务处理非常快速的场景。

Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案。

单 Reactor 多线程 / 多进程

如果要克服「单 Reactor 单线程 / 进程」方案的缺点，那么就需要引入多线程 / 多进程，这样就产生了单 Reactor 多线程 / 多进程的方案。

闻其名不如看其图，先来看看「单 Reactor 多线程」方案的示意图如下：

详细说一下这个方案：

• Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
• 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
• 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；

上面的三个步骤和单 Reactor 单线程方案是一样的，接下来的步骤就开始不一样了：

• Handler 对象不再负责业务处理，只负责数据的接收和发送，Handler 对象通过 read 读取到数据后，会将数据发给子线程里的 Processor 对象进行业务处理；
• 子线程里的 Processor 对象就进行业务处理，处理完后，将结果发给主线程中的 Handler 对象，接着由 Handler 通过 send 方法将响应结果发送给 client；

单 Reator 多线程的方案优势在于能够充分利用多核 CPU 的能，那既然引入多线程，那么自然就带来了多线程竞争资源的问题。

例如，子线程完成业务处理后，要把结果传递给主线程的 Handler 进行发送，这里涉及共享数据的竞争。

要避免多线程由于竞争共享资源而导致数据错乱的问题，就需要在操作共享资源前加上互斥锁，以保证任意时间里只有一个线程在操作共享资源，待该线程操作完释放互斥锁后，其他线程才有机会操作共享数据。

聊完单 Reactor 多线程的方案，接着来看看单 Reactor 多进程的方案。

事实上，单 Reactor 多进程相比单 Reactor 多线程实现起来很麻烦，主要因为要考虑子进程 <-> 父进程的双向通信，并且父进程还得知道子进程要将数据发送给哪个客户端。

而多线程间可以共享数据，虽然要额外考虑并发问题，但是这远比进程间通信的复杂度低得多，因此实际应用中也看不到单 Reactor 多进程的模式。

另外，「单 Reactor」的模式还有个问题，因为一个 Reactor 对象承担所有事件的监听和响应，而且只在主线程中运行，在面对瞬间高并发的场景时，容易成为性能的瓶颈的地方。

多 Reactor 多进程 / 线程

要解决「单 Reactor」的问题，就是将「单 Reactor」实现成「多 Reactor」，这样就产生了第 多 Reactor 多进程 / 线程的方案。

老规矩，闻其名不如看其图。多 Reactor 多进程 / 线程方案的示意图如下（以线程为例）：

方案详细说明如下：

• 主线程中的 MainReactor 对象通过 select 监控连接建立事件，收到事件后通过 Acceptor 对象中的 accept 获取连接，将新的连接分配给某个子线程；
• 子线程中的 SubReactor 对象将 MainReactor 对象分配的连接加入 select 继续进行监听，并创建一个 Handler 用于处理连接的响应事件。
• 如果有新的事件发生时，SubReactor 对象会调用当前连接对应的 Handler 对象来进行响应。
• Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。

多 Reactor 多线程的方案虽然看起来复杂的，但是实际实现时比单 Reactor 多线程的方案要简单的多，原因如下：

• 主线程和子线程分工明确，主线程只负责接收新连接，子线程负责完成后续的业务处理。
• 主线程和子线程的交互很简单，主线程只需要把新连接传给子线程，子线程无须返回数据，直接就可以在子线程将处理结果发送给客户端。

大名鼎鼎的两个开源软件 Netty 和 Memcache 都采用了「多 Reactor 多线程」的方案。

采用了「多 Reactor 多进程」方案的开源软件是 Nginx，不过方案与标准的多 Reactor 多进程有些差异。

具体差异表现在主进程中仅仅用来初始化 socket，并没有创建 mainReactor 来 accept 连接，而是由子进程的 Reactor 来 accept 连接，通过锁来控制一次只有一个子进程进行 accept（防止出现惊群现象），子进程 accept 新连接后就放到自己的 Reactor 进行处理，不会再分配给其他子进程。

---

Proactor

前面提到的 Reactor 是非阻塞同步网络模式，而 Proactor 是异步网络模式。

这里先给大家复习下阻塞、非阻塞、同步、异步 I/O 的概念。

先来看看阻塞 I/O，当用户程序执行 read ，线程会被阻塞，一直等到内核数据准备好，并把数据从内核缓冲区拷贝到应用程序的缓冲区中，当拷贝过程完成，read 才会返回。

注意，阻塞等待的是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程。过程如下图：

知道了阻塞 I/O ，来看看非阻塞 I/O，非阻塞的 read 请求在数据未准备好的情况下立即返回，可以继续往下执行，此时应用程序不断轮询内核，直到数据准备好，内核将数据拷贝到应用程序缓冲区，read 调用才可以获取到结果。过程如下图：

注意，这里最后一次 read 调用，获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是内核态的数据拷贝到用户程序的缓存区这个过程。

举个例子，如果 socket 设置了 O_NONBLOCK 标志，那么就表示使用的是非阻塞 I/O 的方式访问，而不做任何设置的话，默认是阻塞 I/O。

因此，无论 read 和 send 是阻塞 I/O，还是非阻塞 I/O 都是同步调用。因为在 read 调用时，内核将数据从内核空间拷贝到用户空间的过程都是需要等待的，也就是说这个过程是同步的，如果内核实现的拷贝效率不高，read 调用就会在这个同步过程中等待比较长的时间。

而真正的异步 I/O 是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程都不用等待。

当我们发起 aio_read （异步 I/O） 之后，就立即返回，内核自动将数据从内核空间拷贝到用户空间，这个拷贝过程同样是异步的，内核自动完成的，和前面的同步操作不一样，应用程序并不需要主动发起拷贝动作。过程如下图：

举个你去饭堂吃饭的例子，你好比应用程序，饭堂好比操作系统。

阻塞 I/O 好比，你去饭堂吃饭，但是饭堂的菜还没做好，然后你就一直在那里等啊等，等了好长一段时间终于等到饭堂阿姨把菜端了出来（数据准备的过程），但是你还得继续等阿姨把菜（内核空间）打到你的饭盒里（用户空间），经历完这两个过程，你才可以离开。

非阻塞 I/O 好比，你去了饭堂，问阿姨菜做好了没有，阿姨告诉你没，你就离开了，过几十分钟，你又来饭堂问阿姨，阿姨说做好了，于是阿姨帮你把菜打到你的饭盒里，这个过程你是得等待的。

异步 I/O 好比，你让饭堂阿姨将菜做好并把菜打到饭盒里后，把饭盒送到你面前，整个过程你都不需要任何等待。

很明显，异步 I/O 比同步 I/O 性能更好，因为异步 I/O 在「内核数据准备好」和「数据从内核空间拷贝到用户空间」这两个过程都不用等待。

Proactor 正是采用了异步 I/O 技术，所以被称为异步网络模型。

现在我们再来理解 Reactor 和 Proactor 的区别，就比较清晰了。

• Reactor 是非阻塞同步网络模式，感知的是就绪可读写事件。在每次感知到有事件发生（比如可读就绪事件）后，就需要应用进程主动调用 read 方法来完成数据的读取，也就是要应用进程主动将 socket 接收缓存中的数据读到应用进程内存中，这个过程是同步的，读取完数据后应用进程才能处理数据。
• Proactor 是异步网络模式， 感知的是已完成的读写事件。在发起异步读写请求时，需要传入数据缓冲区的地址（用来存放结果数据）等信息，这样系统内核才可以自动帮我们把数据的读写工作完成，这里的读写工作全程由操作系统来做，并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据，操作系统完成读写工作后，就会通知应用进程直接处理数据。

因此，Reactor 可以理解为「来了事件操作系统通知应用进程，让应用进程来处理」，而 Proactor 可以理解为「来了事件操作系统来处理，处理完再通知应用进程」。这里的「事件」就是有新连接、有数据可读、有数据可写的这些 I/O 事件这里的「处理」包含从驱动读取到内核以及从内核读取到用户空间。

举个实际生活中的例子，Reactor 模式就是快递员在楼下，给你打电话告诉你快递到你家小区了，你需要自己下楼来拿快递。而在 Proactor 模式下，快递员直接将快递送到你家门口，然后通知你。

无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式，区别在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式则是基于「已完成」的 I/O 事件。

接下来，一起看看 Proactor 模式的示意图：

介绍一下 Proactor 模式的工作流程：

• Proactor Initiator 负责创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 Asynchronous Operation Processor 注册到内核；
• Asynchronous Operation Processor 负责处理注册请求，并处理 I/O 操作；
• Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor；
• Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；
• Handler 完成业务处理；

可惜的是，在 Linux 下的异步 I/O 是不完善的， aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。

而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP，是由操作系统级别实现的异步 I/O，真正意义上异步 I/O，因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案。

模拟Proactor模式

《Linux高性能服务器编程》中对模拟proactor的解释：

之前提到了使用同步I/O方式模拟出Proactor模式的一种方法。 其原理是：主线程执行数据读写操作，读写完成之后，主线程向工作线程通知这一“完成事件”。那么从工作线程的角度来看，它们就直接获得了数据读写的结果，接下来要做的只是对读写的结果进行逻辑处理。 ​ 使用同步I/O模型(仍然以epoll_wait 为例)模拟出的Proactor模式的工作流程如下：

1. 主线程往epoll内核事件表中注册socket 上的读就绪事件。

2. 主线程调用epoll_wait 等待socket上有数据可读。

3. 当socket 上有数据可读时，epoll_wait 通知主线程。主线程从socket循环读取数据，直到没有更多数据可读，然后将读取到的数据封装成一个请求对象并插入请求队列。

4. 睡眠在请求队列上的某个工作线程被唤醒，它获得请求对象并处理客户请求，然后往epoll内核事件表中注册socket上的写就绪事件。

5. 主线程调用epoll_wait 等待socket可写。

6. 当socket可写时，epoll_wait通知主线程。主线程往socket上写人服务器处理客户请求的结果。

2.3 高效并发模式

并发编程方法的实现有多线程和多进程两种，但这里涉及的并发模式指I/O处理单元与逻辑单元的协同完成任务的方法。

半同步/半异步模式

首先，半同步/半异步模式中的“同步”和“异步”与前面讨论的IO模型中的“同步”和“异步”是完全不同的概念。在I/O模型中,“同步”和“异步”区分的是内核向应用程序通知的是何种I/O事件(是就绪事件还是完成事件)，以及该由谁来完成I/O读写(是应用程序还是内核)。在并发模式中，“同步”指的是程序完全按照代码序列的顺序执行；“异步”指的是程序的执行需要由系统事件来驱动。常见的系统事件包括中断、信号等。比如，图a描述了同步的读操作，而图b则描述了异步的读操作。

按照同步方式运行的线程称为同步线程，按照异步方式运行的线程称为异步线程。显然，异步线程的执行效率高，实时性强，这是很多嵌入式程序采用的模型。但编写以异步方式执行的程序相对复杂，难于调试和扩展，而且不适合于大量的并发。而同步线程则相反，它虽然效率相对较低，实时性较差，但逻辑简单。因此，对于像服务器这种既要求较好的实时性，又要求能同时处理多个客户请求的应用程序，我们就应该同时使用同步线程和异步线程来实现，即采用半同步/半异步模式来实现。

半同步/半异步模式工作流程

• 同步线程用于处理客户逻辑
• 异步线程用于处理I/O事件
• 异步线程监听到客户请求后，就将其封装成请求对象并插入请求队列中
• 请求队列将通知某个工作在同步模式的工作线程来读取并处理该请求对象

半同步/半反应堆

在服务器程序中，如果结合考虑两种事件处理模式和几种I/O模型，则半同步/半异步模式就存在多种变体。其中有一种变体称为半同步/半反应堆(half-sync/half-recactive) 模式，如图示。

半同步/半反应堆工作流程（以Proactor模式为例）

• 主线程充当异步线程，负责监听所有socket上的事件
• 若有新请求到来，主线程接收之以得到新的连接socket，然后往epoll内核事件表中注册该socket上的读写事件
• 如果连接socket上有读写事件发生，主线程从socket上接收数据，并将数据封装成请求对象插入到请求队列中
• 所有工作线程睡眠在请求队列上，当有任务到来时，通过竞争（如互斥锁）获得任务的接管权

半同步/半反应堆模式存在如下缺点：

• 主线程和工作线程共享请求队列。主线程往请求队列中添加任务，或者工作线程从请求队列中取出任务，都需要对请求队列加锁保护，从而白白耗费CPU时间。
• 每个工作线程在同一时间只能处理一个客户请求。如果客户数量较多，而工作线程较少，则请求队列中将堆积很多任务对象，客户端的响应速度将越来越慢。如果通过增加工作线程来解决这一问题，则工作线程的切换也将耗费大量CPU时间。

领导者/追随者模式

领导者/追随者模式是多个工作线程轮流获得事件源集合，轮流监听、分发并处理事件的一种模式。在任意时间点，程序都仅有一个领导者线程，它负责监听I/O事件。而其他线程则都是追随者，它们休眠在线程池中等待成为新的领导者。当前的领导者如果检测到I/O事件，首先要从线程池中推选出新的领导者线程，然后处理I/O事件。此时，新的领导者等待新的I/O事件，而原来的领导者则处理I/O事件，二者实现了并发。领导者/追随者模式包含如下几个组件：句柄集(HandleSet)、 线程集(ThreadSet )、事件处理器( EventHandler)和具体的事件处理器(ConcreteEventHandler)。 它们的关系如图：

其中线程集是所有工作线程(包括领导者线程和追随者线程)的管理者。它负责各线程之间的同步，以及新领导者线程的推选。线程集中的线程在任一时间必处于如下三种状态之一：

• Lcader：线程当前处于领导者身份，负责等待句柄集上的I/O事件。
• Processing：线程正在处理事件。领导者检测到I/O事件之后，可以转移到Processing状态来处理该事件，并调用promote_new_leader 方法推选新的领导者；也可以指定其他追随者来处理事件(Event Handoff)， 此时领导者的地位不变。当处于Processing状态的线程处理完事件之后，如果当前线程集中没有领导者，则它将成为新的领导者，否则它就直接转变为追随者。
• Follower：线程当前处于追随者身份，通过调用线程集的join方法等待成为新的领导者，也可能被当前的领导者指定来处理新的任务。

需要注意的是，领导者线程推选新的领导者和追随者等待成为新领导者这两个操作都将修改线程集，因此线程集提供一个成员Synchronizer来同步这两个操作，以避免竞态条件。

2.4 线程池的实现

线程池的特点：

• 空间换时间，浪费服务器的硬件资源，换取运行效率.
• 池是一组资源的集合,这组资源在服务器启动之初就被完全创建好并初始化,这称为静态资源.
• 当服务器进入正式运行阶段,开始处理客户请求的时候,如果它需要相关的资源,可以直接从池中获取,无需动态分配.
• 当服务器处理完一个客户连接后,可以把相关的资源放回池中,无需执行系统调用释放资源.