epoll使用

1、epoll是什么

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在大数据、高并发、集群等一些名词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。

epoll 是Linux内核中的一种可扩展IO事件处理机制，最早在 Linux 2.5.44内核中引入，可被用于代替POSIX select 和 poll 系统调用，并且在具有大量应用程序请求时能够获得较好的性能（ 此时被监视的文件描述符数目非常大，与旧的 select 和 poll 系统调用完成操作所需 O(n) 不同， epoll能在O(1)时间内完成操作，所以性能相当高），epoll 与 FreeBSD的kqueue类似，都向用户空间提供了自己的文件描述符来进行操作。它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。

2、epoll使用

epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。

使用epoll需要引入头文件：#include <sys/epoll.h>

下面依次介绍epoll系统调用的三个函数：

int epoll_create(int size);

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

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

epoll的事件注册函数，第一个参数是 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队列里。（这样保证同一SOCKET只能被一个线程处理，不会跨越多个线程）

当对方关闭连接(FIN), EPOLLERR，都可以认为是一种EPOLLIN事件，在read的时候分别有0，-1两个返回值。

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

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

注意：如果超时时间为0，必然导致内核不停的调用epoll_wait函数，频率应该是内核的最小时间粒度，其结果是相当于一个死循环调用了，所以导致CPU消耗过高（epoll_wait没有事件触发的情况下）。

3、epoll的两种工作模式

EPOLL事件有两种模型 Level Triggered (LT) 和 Edge Triggered (ET)：

LT(level triggered，水平触发模式)是缺省的工作方式，并且同时支持 block 和 non-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。

ET(edge-triggered，边缘触发模式)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，等到下次有新的数据进来的时候才会再次出发就绪事件。

使用注意事项：
1、使用边缘触发模式时，当检测到可读事件时，需要将缓冲区数据读完，当read()或者write()返回EAGAIN时才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。
2、使用水平触发模式，如果对events设置了EPOLLONESHOT特性，此时也需要如此。在操作ET模式下的EPOLL时，对EPOLLONESHOT没有什么太大的注意点，但是在LT时，就有一些注意的了。前面说过LT会不断触发，所以在处理数据时，不需要在RECV时不断的循环去读一直读到EAGAIN，但如果设置了EPOLLONESHOT后，也得如此办理，否则，就可能会丢掉数据。
3、有篇文件介绍了EPOLLONESHOT在LT模式下和ET模式下的使用，可参考如下链接：
https://blog.csdn.net/liuhengxiao/article/details/46911129
4、单使用epoll是无法完成高性能工作的，一般使用epoll+线程池来完成。epoll负责监听事件，线程池负责具体的任务处理。使用线程是基于以下的考虑：

1. 对于耗时比较长的逻辑，如数据库访问、复杂数值计算等，如果不启用另外的线程处理，主线程就会把时间都花在处理逻辑上，就会影响网络IO的处理和其它请求的逻辑处理，从而影响整体性能。
2. 现在的服务器基本上都是多核多cpu的，通过多线程，可以把线程映射到不同的cpu去执行，充分利用多核多cpu的处理能力。

4、epoll demo

5、epoll+线程池 demo

参考资料：
https://www.cnblogs.com/haippy/archive/2012/01/09/2317269.html
https://blog.csdn.net/shenya1314/article/details/73691088
https://blog.csdn.net/ljx0305/article/details/4065058
https://blog.csdn.net/sparkliang/article/details/4770655