同 I/O 多路复用和信号驱动 I/O 一样，Linux 的 epoll（event poll）API 可以检查多个文件

描述符上的 I/O 就绪状态。epoll 是 Linux 下多路复用IO接口 select/poll 的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

一、阻塞的原理

（1）工作队列

阻塞是进程调度的关键一环，指的是进程在等待某事件（如接收到网络数据）发生之前的等待状态，recv、select和 epoll 都是阻塞方法，以简单网络编程为例

下图中的计算机中运行着A、B、C三个进程，其中进程A执行着上述基础网络程序，一开始，这3个进程都被操作系统的工作队列所引用，处于运行状态，会分时执行

（2）等待队列

当进程A执行到创建 socket 的语句时，操作系统会创建一个由文件系统管理的 socket 对象（如下图）。这个socket对象包含了发送缓冲区、接收缓冲区、等待队列等成员。等待队列是个非常重要的结构，它指向所有需要等待该socket事件的进程。

当程序执行到recv时，操作系统会将进程A从工作队列移动到该socket的等待队列中（如下图）。由于工作队列只剩下了进程B和C，依据进程调度，cpu会轮流执行这两个进程的程序，不会执行进程A的程序。所以进程A被阻塞，不会往下执行代码，也不会占用cpu资源。

ps：操作系统添加等待队列只是添加了对这个“等待中”进程的引用，以便在接收到数据时获取进程对象、将其唤醒，而非直接将进程管理纳入自己之下。上图为了方便说明，直接将进程挂到等待队列之下。

（3）唤醒进程

当 socket 接收到数据后，操作系统将该 socket 等待队列上的进程重新放回到工作队列，该进程变成运行状态，继续执行代码。也由于 socket 的接收缓冲区已经有了数据，recv 可以返回接收到的数据。

二、内核接收网络数据全过程

如下图所示，进程在recv阻塞期间，计算机收到了对端传送的数据（步骤①）。数据经由网卡传送到内存（步骤②），然后网卡通过中断信号通知CPU有数据到达，CPU执行中断程序（步骤③）。此处的中断程序主要有两项功能，先将网络数据写入到对应socket的接收缓冲区里面（步骤④），再唤醒进程A（步骤⑤），重新将进程A放入工作队列中。

唤醒线程的过程如下图所示

三、epoll原理（源码）

（1）创建epoll对象

如下图所示，当某个进程调用 epoll_create 方法时，内核会创建一个 eventpoll 对象（也就是程序中 epfd 所代表的对象）。eventpoll 对象也是文件系统中的一员，和 socket 一样，它也会有等待队列。

最后 epoll_create 生成的文件描述符如下图所示：

/*
 * 此结构体存储在file->private_data中
 */
struct eventpoll {
	// 自旋锁，在kernel内部用自旋锁加锁，就可以同时多线(进)程对此结构体进行操作
	// 主要是保护ready_list
	spinlock_t lock;
	// 这个互斥锁是为了保证在eventloop使用对应的文件描述符的时候，文件描述符不会被移除掉
	struct mutex mtx;
	// epoll_wait使用的等待队列，和进程唤醒有关
	wait_queue_head_t wq;
	// file->poll使用的等待队列，和进程唤醒有关
	wait_queue_head_t poll_wait;
	// 就绪的描述符队列
	struct list_head rdllist;
	// 通过红黑树来组织当前epoll关注的文件描述符
	struct rb_root rbr;
	// 在向用户空间传输就绪事件的时候，将同时发生事件的文件描述符链入到这个链表里面
	struct epitem *ovflist;
	// 对应的user
	struct user_struct *user;
	// 对应的文件描述符
	struct file *file;
	// 下面两个是用于环路检测的优化
	int visited;
	struct list_head visited_list_link;
};

本文讲述的是 kernel 是如何将就绪事件传递给 epoll 并唤醒对应进程上，因此在这里主要聚焦于 (wait_queue_head_t wq) 等成员。

就绪列表的数据结构

就绪列表引用着就绪的socket，所以它应能够快速的插入数据。

程序可能随时调用epoll_ctl添加监视socket，也可能随时删除。当删除时，若该socket已经存放在就绪列表中，它也应该被移除。

所以就绪列表应是一种能够快速插入和删除的数据结构。双向链表就是这样一种数据结构，epoll使用双向链表来实现就绪队列（对应上图的rdllist）。

索引结构

既然epoll将“维护监视队列”和“进程阻塞”分离，也意味着需要有个数据结构来保存监视的socket。至少要方便的添加和移除，还要便于搜索，以避免重复添加。红黑树是一种自平衡二叉查找树，搜索、插入和删除时间复杂度都是O(log(N))，效率较好。epoll使用了红黑树作为索引结构（对应上图的rbr）

ps：因为操作系统要兼顾多种功能，以及由更多需要保存的数据，rdlist并非直接引用socket，而是通过epitem间接引用，红黑树的节点也是epitem对象。同样，文件系统也并非直接引用着socket。为方便理解，本文中省略了某些间接结构。

维护监视列表

创建epoll对象后，可以用epoll_ctl添加或删除所要监听的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语句。如下图所示，内核会将进程A放入eventpoll的等待队列中，阻塞进程。

当socket接收到数据，中断程序一方面修改rdlist，另一方面唤醒eventpoll等待队列中的进程，进程A再次进入运行状态（如下图）。也因为rdlist的存在，进程A可以知道哪些socket发生了变化。

值得注意的是，我们在 close 对应的文件描述符的时候，会自动调用 eventpoll_release 将对应的 file 从其关联的 epoll_fd 中删除。

close fd
      |->filp_close
            |->fput
                  |->__fput
                        |->eventpoll_release
                              |->ep_remove

所以我们在关闭对应的文件描述符后，并不需要通过 epoll_ctl_del 来删掉对应 epoll 中相应的描述符。

得出结论

现在我们看看为什么 epoll 的性能表现会更好。

每次调用 select()和 poll()时，内核必须检查所有在调用中指定的文件描述符。

与之相反，当通过 epoll_ctl()指定了需要监视的文件描述符时，内核会在与打开的文件描述

上下文相关联的列表中记录该描述符。之后每当执行 I/O 操作使得文件描述符成为就

绪态时，内核就在 epoll 描述符的就绪列表中添加一个元素。

（单个打开的文件描述上下文中的一次 I/O 事件可能导致与之相关的多个文件描述符成为就绪态。）之后的epoll_wait()调用从就绪列表中简单地取出这些元素。

每次调用 select()或 poll()时，我们传递一个标记了所有待监视的文件描述符的

数据结构给内核，调用返回时，内核将所有标记为就绪态的文件描述符的数据

结构再传回给我们。

与之相反，在 epoll 中我们使用 epoll_ctl()在内核空间中建

立一个数据结构，该数据结构会将待监视的文件描述符都记录下来。一旦这个

数据结构建立完成，稍后每次调用 epoll_wait()时就不需要再传递任何与文件描

述符有关的信息给内核了，而调用返回的信息中只包含那些已经处于就绪态的

描述符。

转载自：https://blog.csdn.net/weixin_61