一、epoll_create()

• 系统调用epoll_create()会创建一个epoll实例并返回该实例对应的文件描述符fd。在内核中，每个epoll实例会和一个struct eventpoll类型的对象一一对应，该对象是epoll的核心，其声明在fs/eventpoll.c文件中.

• epoll_create的接口定义在这里，主要源码分析如下：

• 首先创建一个struct eventpoll对象：

• 然后创建一个struct file对象，将file中的struct file_operations *f_op设置为全局变量eventpoll_fops，将void *private指向刚创建的eventpoll对象ep：

• 然后设置eventpoll中的file指针：

• ep->file = file;

• 最后将文件描述符添加到当前进程的文件描述符表中，并返回给用户

• fd_install(fd, file);<br data-filtered="filtered">return fd;

• 操作结束后主要结构关系如下图：

【文章福利】小编推荐自己的Linux内核技术交流群:【891587639】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！前100名进群领取，额外赠送一份价值699的内核资料包（含视频教程、电子书、实战项目及代码)

二、epoll_ctl()

• 系统调用epoll_ctl()在内核中的定义如下，各个参数的含义可参见epoll_ctl的man手册

• SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd, struct epoll_event __user *, event)

• epoll_ctl()首先判断op是不是删除操作，如果不是则将event参数从用户空间拷贝到内核中：

接下来判断用户是否设置了EPOLLEXCLUSIVE标志，这个标志是4.5版本内核才有的，主要是为了解决同一个文件描述符同时被添加到多个epoll实例中造成的“惊群”问题，详细描述可以看这里。 这个标志的设置有一些限制条件，比如只能是在EPOLL_CTL_ADD操作中设置，而且对应的文件描述符本身不能是一个epoll实例，下面代码就是对这些限制的检查：

接下来从传入的文件描述符开始，一步步获得struct file对象，再从struct file中的private_data字段获得struct eventpoll对象：

• 如果要添加的文件描述符本身也代表一个epoll实例，那么有可能会造成死循环，内核对此情况做了检查，如果存在死循环则返回错误。这部分的代码目前我还没细看，这里不再贴出。

• 接下来会从epoll实例的红黑树里寻找和被监控文件对应的epollitem对象，如果不存在，也就是之前没有添加过该文件，返回的会是NULL。

ep_find()函数本质是一个红黑树查找过程，红黑树查找和插入使用的比较函数是ep_cmp_ffd()，先比较struct file对象的地址大小，相同的话再比较文件描述符大小。struct file对象地址相同的一种情况是通过dup()系统调用将不同的文件描述符指向同一个struct file对象。

接下来会根据操作符op的不同做不同的处理，这里我们只看op等于EPOLL_CTL_ADD时的添加操作。首先会判断上一步操作中返回的epollitem对象地址是否为NULL，不是NULL说明该文件已经添加过了，返回错误，否则调用ep_insert()函数进行真正的添加操作。在添加文件之前内核会自动为该文件增加POLLERR和POLLHUP事件。

三、ep_insert()

• ep_insert()函数中，首先判断epoll实例中监视的文件数量是否已超过限制，没问题则为待添加的文件创建一个epollitem对象：

接下来是对epollitem的初始化：

接下来是比较重要的操作：将epollitem对象添加到被监视文件的等待队列上去。等待队列实际上就是一个回调函数链表，定义在/include/linux/wait.h文件中。因为不同文件系统的实现不同，无法直接通过struct file对象获取等待队列，因此这里通过struct file的poll操作，以回调的方式返回对象的等待队列，这里设置的回调函数是ep_ptable_queue_proc:

• 上面代码中结构体ep_queue的作用是能够在poll的回调函数中取得对应的epollitem对象，这种做法在Linux内核里非常常见。

• 在回调函数ep_ptable_queue_proc中，内核会创建一个struct eppoll_entry对象，然后将等待队列中的回调函数设置为ep_poll_callback()。也就是说，当被监控文件有事件到来时，比如socker收到数据时，ep_poll_callback()会被回调。ep_ptable_queue_proc()代码如下：

• ppoll_entry和epitem等结构关系如下图：

• 在回到ep_insert()函数中。ep_item_poll()调用完成之后，会将epitem中的fllink字段添加到struct file中的f_ep_links链表中，这样就可以通过struct file找到所有对应的struct epollitem对象，进而通过struct epollitem找到所有的epoll实例对应的struct eventpoll。

spin_lock(&tfile->f_lock); 

list_add_tail_rcu(&epi->fllink, &tfile->f_ep_links); 

spin_unlock(&tfile->f_lock);

然后就是将epollitem插入到红黑树中：1 ep_rbtree_insert(ep, epi) 最后再更新下状态就返回了，插入操作也就完成了。 在返回之前还会判断一次刚才添加的文件是不是当前已经有事件就绪了，如果是就将其加入到epoll的就绪链表中，关于就绪链表放到下一部分中讲，这里略过。

• 最后是我画的几个结构体之间的结构图。

四、分析如下

• 在通过epoll_ctl(2)向epoll中添加被监视文件描述符时，会将ep_poll_callback()作为回调函数添加被监视文件的等待队列中。下面分析ep_poll_callback()函数

• 判断返回的事件掩码里是否设置了标志位POLLFREE（什么时候会设置该标志？），如果是则将当前等待对象从文件描述符的等待队列中删除(疑问：注释是什么意思？为什么不需要加锁？）。

• 接下来对epoll的实例加锁：

接下来判断epitem中的事件掩码是不是并没有包括任何poll(2)事件，如果是的话，则解锁后直接返回：

什么时候会出现上述情况呢？注释里也说了，就是在设置了EPOLLONESHOT标志的时候。对EPOLLONESHOT标志的处理是在epoll_wait()的返回过程，调用ep_send_events_proc()的时候，如果设置了EPOLLONESHOT标志则将EP_PRIVATE_BITS以外的标志位全部清0：

接下来判断返回的事件里是否有用户真正感兴趣的事件，没有则解锁后返回，否则继续。

如果此时就绪链表rdllist没有被其他进程访问，则直接将当前文件描述符添加到rdllist链表中，否则的话添加到ovflist链表中。ovflist默认值是EP_UNACTIVE_PTR，epoll_wait()遍历rdllist之前会把ovflist设置为NULL，遍历完再恢复为EP_UNACTIVE_PTR，因此通过判断ovflist的值是不是EP_UNACTIVE_PTR可知此时rdllist是不是正在被访问。

如果是描述符是添加到ovflist链表中，说明此时已经有ep_wait()准备返回了，因此不用再唤醒epoll实例的等待队列，因此1062行直接跳到解锁处；否则的话，则唤醒因为调用epoll_wait()而等待在epoll实例等待队列上的进程（这里最多只会唤醒一个进程）：

如果epoll实例的poll队列非空，也会唤醒等待在poll队列上的进程，不过是在解锁后才会进行唤醒操作。

最后解锁并返回：

注意到ep_poll_callback()的返回值和EPOLLEXCLUSIVE标志有关，该标志是用来处理这种情况：当多个进程中的不同epoll实例在监视同一个文件描述符时，如果该文件描述符上有事件发生，则所有的epoll实例所在进程都将被唤醒，这样有可能造成“惊群”(thundering herd)。

五、epoll惊群原因分析

• 考虑如下情况（实际一般不会做，这里只是举个例子）：

在主线程中创建一个socket、绑定到本地端口并监听 

在主线程中创建一个epoll实例(epoll_create(2)) 

将监听socket添加到epoll中(epoll_ctl(2)) 

创建多个子线程，每个子线程都共享步骤2里创建的同一个epoll文件描述符，然后调用epoll_wait(2)等待事件到来accept(2) 

请求到来，新连接建立 

这里的问题就是，在第5步的时候，会有多少个线程被唤醒而从epoll_wait()调用返回？答案是不一定，可能只有一个，也可能有部分，也可能是全部。当然在多个线程都唤醒的情况下，只会有一个线程accept()调用会成功。

• 为何如此？从内核代码分析，原因如下：

• 因为__wake_up_common()的调用是从wake_up_locked()开始的，__wake_up_common的各个参数值为：

• 局部变量curr的值可以通过epoll_wait()的源码得到，具体为：

curr->flags: WQ_FLAG_EXCLUSIVE 

curr->func: default_wake_function 

default_wake_function调用的是try_to_wake_up。而try_to_wake_up只有在要唤醒的进程状态不是

TASK_NORMAL时才会返回0，TASK_NORMAL的定义是(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)。

• 因此__wake_up_common里的if条件会在第一次判断的时候就满足，唤醒一个进程后便返回了，那为什么实际测试会发现有多个进程被唤醒呢？

• 原因就在于这个唯一被唤醒的进程。

• 当某个等待在epoll实例上的进程被唤醒后，最终会进入到ep_scan_ready_list() 这个函数中，ep_scan_ready_list()会以回调方式调用ep_send_events_proc()来将数据复制到用户空间。而ep_scan_ready_list()函数在返回之前会再次判断epoll的就绪链表rdllist是否为空，如果不为空的话，就会再唤醒其他进程！下面就是ep_scan_ready_list()返回之前的判断操作：

• 而在水平触发方式下，从就绪链表中移出来的文件描述符，如果当前仍有事件就绪（可读、可写等），会在复制到用户空间后被再次添加到就绪链表中：
  

• 因此在水平触发模式下，被唤醒的进程又会去唤醒其他进程，除非当前事件已经被处理完或者所有进程都已经被唤醒（被唤醒的进程会从epoll等待队列上移除）。