????????同 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个进程都被操作系统的工作队列所引用，处于运行状态，会分时执行
?
工作队列中有A、B和C三个进程
?
（2）等待队列
当进程A执行到创建socket的语句时，操作系统会创建一个由文件系统管理的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()时就不需要再传递任何与文件描
述符有关的信息给内核了，而调用返回的信息中只包含那些已经处于就绪态的
描述符。
?
参考：
《Linux-UNIX系统编程手册》
用于学习整理