多路I/O复用（select epoll）

对比

Ø  select缺点:

1、最大并发数限制：使用32个整数的32位，即32*32=1024来标识fd，虽然可修改，但是有以下第二点的瓶颈；

2、效率低：每次都会线性扫描整个fd_set，集合越大速度越慢（select返回后，如果数据就绪，需要遍历整个fd_set）；

3、内核/用户空间内存拷贝问题（select函数开始时，将fd_set从用户空间拷贝进内核，函数返回时，内核将fd_set拷贝到用户空间）。

（poll的机制与select类似，与select在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。）

Ø  对2、3缺点的解读：

（注意，一般select函数只能处理一次查询，即查看是否有监听的文件描述符状态有效，这个状态可以是可读，也可以是可写，所以，select一般在一个循环里面）

1、效率低：每次都会线性扫描整个fd_set，集合越大速度越慢，其实有效的描述符在集合里面的占比是很小的，如果仅仅返回有效的描述符，可以大大提高效率。epoll通过建立一个list，存储有效的描述符，提高了效率。

2、内核/用户空间内存拷贝：根源在于select函数的形式，每次调用，所有描述符集合（fd_set）都会在用户/内核空间互相传递，实际上可能对于多次select调用，有大量相同的不变的描述符，如果能存储在内核空间，那么每次就可以仅仅交互添加或删除的部分，这将大大提升效率。epoll函数就是采用的这种方式。

Ø  epoll的提升：

1、本身没有最大并发连接的限制，仅受系统中进程能打开的最大文件数目限制；

2、效率提升：只有活跃的socket才会主动的去调用callback函数；

3、省去不必要的内存拷贝：epoll通过内核与用户空间mmap同一块内存实现。

当然，以上的优缺点仅仅是特定场景下的情况：高并发，且任一时间只有少数socket是活跃的。

如果在并发量低，socket都比较活跃的情况下，select就不见得比epoll慢了（就像我们常常说快排比插入排序快，但是在特定情况下这并不成立）。

select原理概述

Ø  每次调用select时，会发生以下事情：

1、从用户空间拷贝fd_set到内核空间；

2、注册回调函数__pollwait；

3、遍历所有fd，对全部指定设备做一次poll（这里的poll是一个文件操作，它有两个参数，一个是文件fd本身，一个是当设备尚未就绪时调用的回调函数__pollwait，这个函数把设备自己特有的等待队列传给内核，让内核把当前的进程挂载到其中）；

4、当设备就绪时，设备就会唤醒在自己特有等待队列中的【所有】节点，于是当前进程就获取到了完成的信号。poll文件操作返回的是一组标准的掩码，其中的各个位指示当前的不同的就绪状态（全0为没有任何事件触发），根据mask可对fd_set赋值；

5、如果所有设备返回的掩码都没有显示任何的事件触发，就去掉回调函数的函数指针，进入有限时的睡眠状态，再恢复和不断做poll，再作有限时的睡眠，直到其中一个设备有事件触发为止。

6、只要有事件触发，系统调用返回，将fd_set从内核空间拷贝到用户空间，回到用户态，用户就可以对相关的fd作进一步的读或者写操作了。

epoll原理概述

Ø  调用epoll_create时，做了以下事情（实际上就是初始化）：

1、内核帮我们在epoll文件系统里建了个file结点；

2、在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket；

3、建立一个list链表，用于存储准备就绪的事件。

Ø  调用epoll_ctl时，做了以下事情（添加监听对象）：

1、把socket放到epoll文件系统里file对象对应的红黑树上；

2、给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。

Ø  调用epoll_wait时，做了以下事情：

观察list链表里有没有数据。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已。

总结如下：

一颗红黑树，一张准备就绪句柄链表，少量的内核cache，解决了大并发下的socket处理问题。

1、执行epoll_create时，创建了红黑树和就绪链表；

2、执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据;

3、执行epoll_wait时立刻返回准备就绪链表里的数据即可。

两种模式的区别：

LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时重复返回这个句柄，而ET模式仅在第一次返回。

两种模式的实现：

当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时我们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后，epoll_wait检查这些socket，如果是LT模式，并且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表。所以，LT模式的句柄，只要它上面还有事件，epoll_wait每次都会返回。

epoll函数详解

1、epoll接口

epoll操作过程需要三个接口，分别如下：

#include <sys/epoll.h>

int epoll_create(int size);

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

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

 

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

EPOLL_CTL_ADD：注册新的fd到epfd中；

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

EPOLL_CTL_DEL：从epfd中删除一个fd；

第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事。

（3） int epoll_wait(int epfd, struct epoll_event * events, intmaxevents, int timeout);

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

2、工作模式

epoll对文件描述符的操作有两种模式：LT（leveltrigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：

LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。

ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

 

参考：http://www.cnblogs.com/Anker/p/3265058.html