linux epoll使用原理

1 介绍

       Epoll 是一种高效的管理socket的模型，相对于select和poll来说具有更高的效率和易用性。传统的select以及poll的效率会因为 socket数量的线形递增而导致呈二次乃至三次方的下降，而epoll的性能不会随socket数量增加而下降。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。

       Epoll是为处理大批量句柄而做了改进的poll：支持一个进程打开较大数目的文件描述符(fd)，epoll则没有对描述符数目的限制，它所支持的文件描述符上限是整个系统最大可以打开的文件数目。

2 效率问题

      传统的select/poll的一个致命弱点就是当你拥有一个很大的socket集合时，不过任一时间只有部分socket是活跃的，select/poll每次调用都会线性扫描整个socket集合，这将导致IO处理效率呈现线性下降。

     但是，epoll不存在这个问题，它只会对活跃的socket进行操作，这是因为在内核实现中，epoll是根据每个fd上面的callback函数实现的。因此，只有活跃的socket才会主动去调用callback函数，其他idle状态socket则不会。在这一点上，epoll实现了一个伪AIO，其内部推动力在内核。

3 使用方式

     epoll的接口非常简单，一共就三个函数：

1. int epoll_create(int size);

创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：

EPOLL_CTL_ADD：注册新的fd到epfd中；

EPOLL_CTL_MOD：修改已经注册的fd的监听事件；

EPOLL_CTL_DEL：从epfd中删除一个fd；

第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：

typedef union epoll_data {

    void *ptr;

    int fd;

    __uint32_t u32;

    __uint64_t u64;

} epoll_data_t;

struct epoll_event {

    __uint32_t events; /* Epoll events */

    epoll_data_t data; /* User data variable */

};

events可以是以下几个宏的集合：

EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；

EPOLLOUT：表示对应的文件描述符可以写；

EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；

EPOLLERR：表示对应的文件描述符发生错误；

EPOLLHUP：表示对应的文件描述符被挂断；

EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。

EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。

4、关于ET、LT两种工作模式：

1. LT模式（Level Triggered，水平触发）

该模式是epoll的缺省工作模式，其同时支持阻塞和非阻塞socket。内核会告诉开发者一个文件描述符是否就绪，如果开发者不采取任何操作，内核仍会一直通知。

2. ET模式（Edge Triggered，边缘触发）

该模式是一种高速处理模式，当且仅当状态发生变化时才会获得通知。在该模式下，其假定开发者在接收到一次通知后，会完整地处理该事件，因此内核将不再通知这一事件。注意，缓冲区中还有未处理的数据不能说是状态变化，因此，在ET模式下，开发者如果只读取了一部分数据，其将再也得不到通知了。正确的做法是，开发者自己确认读完了所有的字节（一直调用read/write直到出错EAGAGIN为止）。

Nginx默认采用的就是ET（边缘触发）。

4 epoll高效性探讨

    （1）select/poll每次调用都要传递所要监控的所有fd给select/poll系统调用，这意味着每次调用select/poll时都要将fd列表从用户空间拷贝到内核，当fd数目很多时，这会造成性能低效。对于epoll_wait，每次调用epoll_wait时，其不需要将fd列表传递给内核，epoll_ctl不需要每次都拷贝所有的fd列表，只需要进行增量式操作。因此，在调用epoll_create函数之后，内核已经在内核开始准备数据结构用于存放需要监控的fd了。其后，每次epoll_ctl只是对这个数据结构进行简单的维护操作即可。

     （2）内核使用slab机制，为epoll提供了快速的数据结构。在内核里，一切都是文件。因此，epoll向内核注册了一个文件系统，用于存储所有被监控的fd。当调用epoll_create时，就会在这个虚拟的epoll文件系统中创建一个file节点。epoll在被内核初始化时，同时会分配出epoll自己的内核告诉cache区，用于存放每个我们希望监控的fd。这些fd会以红黑树的形式保存在内核cache里，以支持快速查找、插入和删除。这个内核高速cache，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好想要的size的内存对象，每次使用时都使用空闲的已分配好的对象。

     （3）当调用epoll_ctl往epfd注册百万个fd时，epoll_wait仍然能够快速返回，并有效地将发生的事件fd返回给用户。原因在于，当我们调用epoll_create时，内核除了帮我们在epoll文件系统新建file节点，同时在内核cache创建红黑树用于存储以后由epoll_ctl传入的fd外，还会再建立一个list链表，用于存储准备就绪的事件。当调用epoll_wait时，仅仅观察这个list链表中有无数据即可。如果list链表中有数据，则返回这个链表中的所有元素；如果list链表中没有数据，则sleep然后等到timeout超时返回。所以，epoll_wait非常高效，而且，通常情况下，即使我们需要监控百万计的fd，但大多数情况下，一次也只返回少量准备就绪的fd而已。因此，每次调用epoll_wait，其仅需要从内核态复制少量的fd到用户空间而已。那么，这个准备就绪的list链表是怎么维护的呢？过程如下：当我们执行epoll_ctl时，除了把fd放入到epoll文件系统里file对象对应的红黑树之外，还会给内核中断处理程序注册一个回调函数，其告诉内核，如果这个fd的中断到了，就把它放到准备就绪的list链表中。