epoll原理 从事服务端开发，必须联系网络编程。Epoll 作为 Linux 必要的技术是下高性能网络服务器，Nginx、Redis、Skynet 而且大多数游戏服务器都使用这种多路复用技术。 Epoll 很重要，但是 Epoll 与 Select 有什么区别？Epoll 高效的原因是什么？
虽然网上有很多解释 Epoll 文章，但要么太简单，要么陷入源码分析，很少有通俗易懂的。
所以作者决定写这篇文章，这样缺乏专业背景知识的读者也能理解 Epoll 本文的核心思想是：让读者清楚地理解 Epoll 为什么性能好？
文章会从网卡接收数据的流程讲起，串联起 CPU 中断、操作系统进程调度等知识，然后逐步分析阻塞接收数据Select 到 Epoll 进化过程；最后探究 Epoll 实现细节。
从网卡接收数据开始
下面是典型的计算机结构图，由计算机组成 CPU、了解存储器(内存)、网络接口等部件 Epoll 本质的第一步是从硬件的角度看计算机如何接收网络数据。
计算机结构图(图片来源:Linux 微型计算机组成结构内核完全注释)
下图显示了网卡接收数据的过程：
在 1 网卡在网线上收到数据。 经过 2 硬件电路传输阶段。 最终 3 将数据写入内存中的某个地址。 这个过程涉及到 DMA 传输、IO 与硬件相关的知识，如通路选择，但我们只需要知道：网卡将接收到的数据写入内存。
网卡接收数据的过程
网卡接收的数据通过硬件传输存储在内存中，操作系统可以读取。
如何接收数据？
了解 Epoll 本质的第二步，要从 CPU 从数据接收的角度来看。要理解这个问题，首先要理解一个概念:中断。
计算机执行程序时，会有优先级要求。例如，当计算机收到断电信号时，应立即保存数据。保存数据的程序具有较高的优先级（电容器可以保存少量电源 CPU 短时间运行)。
一般来说，硬件产生的信号需要 CPU 立即做出回应，否则数据可能会丢失，因此其优先级很高。
CPU 应中断正在执行的程序并做出响应；当 CPU 在完成硬件响应后，重新执行用户程序。
中断过程如下图所示，类似于函数调用，但函数调用是事先确定位置，中断位置由信号决定。
调用中断程序
以键盘为例，当用户按下键盘时，键盘会给出 CPU 中断引脚发出高电平，CPU 可以捕获此信号，然后执行键盘中断程序。
下图显示了各种硬件通过中断和 CPU 交互过程：
CPU 中断(图片来源:net.pku.edu.cn)
现在你可以回答你怎么知道你已经收到了数据？这个问题：当网卡将数据写入内存时，网卡会向前移动 CPU 通过发出中断信号，操作系统可以知道新数据的到来，然后通过网卡中断程序处理数据。
为什么进程堵塞不占用 CPU 资源?
了解 Epoll 本质的第三步是从操作系统过程调度的角度看数据接收。阻塞是过程调度的关键环节，是指等待事件（如接收网络数据）前的等待状态，Recv、Select 和 Epoll 都是阻塞方法。
下面分析一下为什么过程堵塞不占用 CPU 为了简单起见，我们来自普通人 Recv 接收开始分析，先看下面的代码:
//创建socket int s = socket(AF_INET, SOCK_STREAM, 0); //绑定 bind(s, …) //监听 listen(s, …) //接受客户端连接 int c = accept(s, …) //接收客户端数据 recv(c, …); //打印数据 printf(…) 这是最基本的网络编程代码，先新建 Socket 依次调用对象 Bind、Listen 与 Accept，最后调用 Recv 接收数据。
Recv 当程序运行到达时，这是一种阻塞方法 Recv 它会一直等待，直到收到数据。那么阻塞的原理是什么呢？
工作队列
为了支持多任务，实现过程调度的功能，操作系统将过程分为几种状态和等待。
运行状态是进程获得 CPU 使用权正在执行代码状态；等待状态是阻塞状态，例如上述程序运行到 Recv 程序将从运行状态转变为等待状态，接收到数据后再转换为运行状态。
由于速度快，操作系统会分时执行各种操作状态的过程，看起来像是同时执行多个任务。
运行在下图计算机中 A、B 与 C 三个过程，包括过程 A 一开始，执行上述基本网络程序 3 操作系统的工作队列引用了一个过程，处于运行状态，将分时执行。
有工作队列 A、B 和 C 三个进程
等待队列
当进程 A 执行到创建 Socket 操作系统将创建由文件系统管理的语句 Socket 对象(下图)。
创建 Socket
这个 Socket 对象包括发送缓冲区、接收缓冲区和等待队列。等待队列是一个非常重要的结构，它指向所有需要等待的人 Socket 事件的过程。
当程序执行时 Recv 时，操作系统会将进程 A 从工作队列移动到此 Socket 等待队列(如下图所示)。
Socket 的等待队列
因为工作队列只剩下过程了 B 和 C，根据进程调度，CPU 这两个过程的程序将轮流执行，不会执行进程 A 程序。所以过程 A 被堵塞，不执行代码，不占用 CPU 资源。
注：在操作系统中添加等待列只是在等待过程中添加引用，以获取过程对象并在收到数据时唤醒它，而不是直接将过程管理纳入自己。为了方便说明，上图直接将过程挂在等待列下。
唤醒进程
当 Socket 操作系统接收到数据后，会 Socket 等待队列上的过程回到工作队列，过程变成运行状态，继续执行代码。
同时由于 Socket 接收缓冲区已有数据，Recv 收到的数据可以返回。
内核接收网络数据全过程
这一步，贯穿网卡、中断和过程调度的知识，描述阻塞 Recv 接下来，内核接收数据的全过程。
内核接收数据的全过程
如上图所示，过程在 Recv 阻塞期间：
计算机收到对端传输的数据(步骤 ①) 数据通过网卡传输到内存(步骤) ②) 然后网卡通过中断信号通知 CPU 数据到达，CPU 执行中断程序(步骤) ③) 这里的中断程序主要有两个功能，首先将网络数据写入对应 Socket 在接收缓冲区(步骤 ④)，再唤醒进程 A(步骤 ⑤)，重新将进程 A 在工作队列中。
唤醒过程如下图所示：
唤醒进程
以上是内核接收数据的全过程。在这里，我们可能会考虑两个问题：
操作系统如何知道网络数据对应哪个？ Socket? 如何同时监控多个 Socket 的数据? 第一个问题:因为一个 Socket 与端口号相对应，包含在网络数据包中 IP 与端口信息相对应的内核可以通过端口号找到 Socket。
当然，为了提高处理速度，操作系统将保持端口号到 Socket 快速读取索引结构。
第二个问题是多路复用的重中之重，也正是本文后半部分的重点。
同时监控多个 Socket 的简单方法
服务端需要管理多个客户端连接， Recv 只能监控单个 Socket，在这种矛盾下，人们开始寻求监视 Socket 的方法。Epoll 本质是有效监控多个 Socket。
从历史发展的角度来看，必然会有一种不太有效的方法，人们会改进，就像 Select 之于 Epoll。先了解不太高效的 Select，能更好地理解 Epoll 的本质。
假如能够预先传入一个 Socket 如果列表中有列表 Socket 没有数据，直到有一个挂起过程 Socket 收到数据，唤醒过程。这种方法非常直接，也是 Select 设计理念。
为了便于理解，我们先复习 Select 用法。在下面的代码中，首先准备一个数组 FDS，让 FDS 存储所有需要监控的存储，存储所有需要监控的存储 Socket。
然后调用 Select，如果 FDS 中的所有 Socket 没有数据，Select 直到有一个 Socket 接收数据，Select 返回，唤醒过程。
用户可以遍历 FDS，通过 FD_ISSET 判断具体哪一个 Socket 收到数据，然后进行处理。
int s = socket(AF_INET, SOCK_STREAM, 0); bind(s, …) listen(s, …)
int fds[] = 存储需要监控socket
while(1){ int n = select(…, fds, …) for(int i=0; i < fds.count; i ){ if(FD_ISSET(fds[i], …)){ //fds[i]的数据处理 } } } Select 的流程
Select 如果程序同时监控下图，实现思路非常直接。 Sock1、Sock2 和 Sock3 三个 Socket，那么在调用 Select 之后，操作系统将进程移动 A 分别加入这三个 Socket 在等待队列中。
操作系统将进程 A 分别加入这三个 Socket 在等待队列中
当任何一个 Socket 中断程序将在收到数据后唤起程。下图展示了 Sock2 接收到了数据的处理流程：
Sock2 接收到了数据，中断程序唤起进程 A
注：Recv 和 Select 的中断回调可以设置成不同的内容。
所谓唤起进程，就是将进程从所有的等待队列中移除，加入到工作队列里面，如下图所示：
将进程 A 从所有等待队列中移除，再加入到工作队列里面
经由这些步骤，当进程 A 被唤醒后，它知道至少有一个 Socket 接收了数据。程序只需遍历一遍 Socket 列表，就可以得到就绪的 Socket。
这种简单方式行之有效，在几乎所有操作系统都有对应的实现。但是简单的方法往往有缺点，主要是：
每次调用 Select 都需要将进程加入到所有监视 Socket 的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历，而且每次都要将整个 FDS 列表传递给内核，有一定的开销。 正是因为遍历操作开销大，出于效率的考量，才会规定 Select 的最大监视数量，默认只能监视 1024 个 Socket。
进程被唤醒后，程序并不知道哪些 Socket 收到数据，还需要遍历一次。 那么，有没有减少遍历的方法?有没有保存就绪 Socket 的方法?这两个问题便是 Epoll 技术要解决的。
补充说明：本节只解释了 Select 的一种情形。当程序调用 Select 时，内核会先遍历一遍 Socket，如果有一个以上的 Socket 接收缓冲区有数据，那么 Select 直接返回，不会阻塞。
这也是为什么 Select 的返回值有可能大于 1 的原因之一。如果没有 Socket 有数据，进程才会阻塞。
Epoll 的设计思路
Epoll 是在 Select 出现 N 多年后才被发明的，是 Select 和 Poll(Poll 和 Select 基本一样，有少量改进)的增强版本。Epoll 通过以下一些措施来改进效率：
措施一：功能分离
Select 低效的原因之一是将“维护等待队列”和“阻塞进程”两个步骤合二为一。
相比 Select，Epoll 拆分了功能
如上图所示，每次调用 Select 都需要这两步操作，然而大多数应用场景中，需要监视的 Socket 相对固定，并不需要每次都修改。
Epoll 将这两个操作分开，先用 epoll_ctl 维护等待队列，再调用 epoll_wait 阻塞进程。显而易见地，效率就能得到提升。
为方便理解后续的内容，我们先了解一下 Epoll 的用法。如下的代码中，先用 epoll_create 创建一个 Epoll 对象 Epfd，再通过 epoll_ctl 将需要监视的 Socket 添加到 Epfd 中，最后调用 epoll_wait 等待数据：
int s = socket(AF_INET, SOCK_STREAM, 0); bind(s, …) listen(s, …)
int epfd = epoll_create(…); epoll_ctl(epfd, …); //将所有需要监听的socket添加到epfd中
while(1){ int n = epoll_wait(…) for(接收到数据的socket){ //处理 } } 功能分离，使得 Epoll 有了优化的可能。
措施二：就绪列表
Select 低效的另一个原因在于程序不知道哪些 Socket 收到数据，只能一个个遍历。如果内核维护一个“就绪列表”，引用收到数据的 Socket，就能避免遍历。
就绪列表示意图
如上图所示，计算机共有三个 Socket，收到数据的 Sock2 和 Sock3 被就绪列表 Rdlist 所引用。
当进程被唤醒后，只要获取 Rdlist 的内容，就能够知道哪些 Socket 收到数据。
Epoll 的原理与工作流程
本节会以示例和图表来讲解 Epoll 的原理和工作流程。
创建 Epoll 对象
如下图所示，当某个进程调用 epoll_create 方法时，内核会创建一个 eventpoll 对象(也就是程序中 Epfd 所代表的对象)。
内核创建 eventpoll 对象
eventpoll 对象也是文件系统中的一员，和 Socket 一样，它也会有等待队列。
创建一个代表该 Epoll 的 eventpoll 对象是必须的，因为内核要维护“就绪列表”等数据，“就绪列表”可以作为 eventpoll 的成员。
维护监视列表
创建 Epoll 对象后，可以用 epoll_ctl 添加或删除所要监听的 Socket。以添加 Socket 为例。
添加所要监听的 Socket
如上图，如果通过 epoll_ctl 添加 Sock1、Sock2 和 Sock3 的监视，内核会将 eventpoll 添加到这三个 Socket 的等待队列中。
当 Socket 收到数据后，中断程序会操作 eventpoll 对象，而不是直接操作进程。
接收数据
当 Socket 收到数据后，中断程序会给 eventpoll 的“就绪列表”添加 Socket 引用。
给就绪列表添加引用
如上图展示的是 Sock2 和 Sock3 收到数据后，中断程序让 Rdlist 引用这两个 Socket。
eventpoll 对象相当于 Socket 和进程之间的中介，Socket 的数据接收并不直接影响进程，而是通过改变 eventpoll 的就绪列表来改变进程状态。
当程序执行到 epoll_wait 时，如果 Rdlist 已经引用了 Socket，那么 epoll_wait 直接返回，如果 Rdlist 为空，阻塞进程。
阻塞和唤醒进程
假设计算机中正在运行进程 A 和进程 B，在某时刻进程 A 运行到了 epoll_wait 语句。
epoll_wait 阻塞进程
如上图所示，内核会将进程 A 放入 eventpoll 的等待队列中，阻塞进程。
当 Socket 接收到数据，中断程序一方面修改 Rdlist，另一方面唤醒 eventpoll 等待队列中的进程，进程 A 再次进入运行状态(如下
图)。Epoll 唤醒进程
也因为 Rdlist 的存在，进程 A 可以知道哪些 Socket 发生了变化。
Epoll 的实现细节
至此，相信读者对 Epoll 的本质已经有一定的了解。但我们还需要知道 eventpoll 的数据结构是什么样子?
此外，就绪队列应该使用什么数据结构?eventpoll 应使用什么数据结构来管理通过 epoll_ctl 添加或删除的 Socket?
Epoll 原理示意图，图片来源：《深入理解 Nginx：模块开发与架构解析(第二版)》，陶辉
如上图所示，eventpoll 包含了 Lock、MTX、WQ(等待队列)与 Rdlist 等成员，其中 Rdlist 和 RBR 是我们所关心的。
就绪列表的数据结构
就绪列表引用着就绪的 Socket，所以它应能够快速的插入数据。程序可能随时调用 epoll_ctl 添加监视 Socket，也可能随时删除。
当删除时，若该 Socket 已经存放在就绪列表中，它也应该被移除。所以就绪列表应是一种能够快速插入和删除的数据结构。
双向链表就是这样一种数据结构，Epoll 使用双向链表来实现就绪队列(对应上图的 Rdlist)。
索引结构
既然 Epoll 将“维护监视队列”和“进程阻塞”分离，也意味着需要有个数据结构来保存监视的 Socket，至少要方便地添加和移除，还要便于搜索，以避免重复添加。
红黑树是一种自平衡二叉查找树，搜索、插入和删除时间复杂度都是 O(log(N))，效率较好，Epoll 使用了红黑树作为索引结构(对应上图的 RBR)。
注：因为操作系统要兼顾多种功能，以及有更多需要保存的数据，Rdlist 并非直接引用 Socket，而是通过 Epitem 间接引用，红黑树的节点也是 Epitem 对象。
同样，文件系统也并非直接引用着 Socket。为方便理解，本文中省略了一些间接结构。
总结
Epoll 在 Select 和 Poll 的基础上引入了 eventpoll 作为中间层，使用了先进的数据结构，是一种高效的多路复用技术。
这里也以表格形式简单对比一下 Select、Poll 与 Epoll，结束此文。希望读者能有所收获。