select介绍
select创建了3个文件描述符集（fd_set）并拷贝到内核中，分别监听读、写、异常动作。select可以监听的文件描述符受到单个进程所能打开的fd的限制，默认为1024。采用轮询方式，遍历所有的fd，最后返回一个文件描述符是否就绪的mask掩码，并根据mask掩码给fd_set赋值。将之前的fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判断。应用程序索引就绪文件描述符的时间复杂度是O(n)。再次调用select时，需要将新的fd_set监听文件描述符拷贝传入进内核。select只能工作在相对较低下的LT模式。
select的缺点
（1）select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024。可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低。
（2）对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
（3）需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。
poll介绍
将struct_pollfd结构体数组拷贝到内核中进行监听。poll采用链表poll_list来进行文件描述符的存储，因此poll可以监听的文件描述符数为系统可以打开的最大文件描述符数（65535）。采用轮询方式，查询每个fd的状态，如果就绪，内核就修改fd对应的revents的值，而events成员保持不变，因此下次调用poll时，应用程序无需重置pollfd类型的事件集参数。将之前传入的struct_pollfd结构体数组拷贝传出到用户态，并返回就绪文件描述符的总个数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判读。应用程序索引就绪文件描述符的时间复杂度是O(n)。poll只能工作在相对较低下的LT模式。
poll的缺点
（1）大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
（2）poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
epoll介绍
执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符)，监听的文件描述符数为系统可以打开的最大文件描述符数（65535）。接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核，内核会在红黑树上添加相应的结点，并注册回调函数ep_poll_callback()，内核在检测到某文件描述符可读/可写时就调用回调函数callback,该回调函数将文件描述符放入就绪链表rdllist中。epoll_wait()函数只需要观察rdllist中有无就绪的文件描述符即可，内核将就绪的文件描述符事件复制到传入的epoll_event结构体数组中返回给用户空间，所以用户只用遍历依次处理即可，即应用程序索引就绪文件描述符的时间复杂度是O（1）。这里返回的文件描述符是通过mmap让内核和用户空间共享同一块内存传递的，减少了不必要的拷贝。再次调用epoll系统调用，不用重建红黑树，直接沿用已经存在的即可。epoll支持ET模式，当内核将该事件通知给用户后，用户必须立即处理，这样就减少了可读、可写和异常事件被触发的次数。
epoll的优点
（1）没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。
（2）效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
（3）内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
epoll对文件描述符操作的两种模式
（1）LT（level_trigger）模式：是缺省的工作方式，并且同时支持block和no-block_socket，当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。
（2）ET（edge_trigger）模式：)是高速工作方式，只支持no-block_socket，当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。
ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
select、poll、epoll区别
在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。)
如果没有大量的idle-connection或者dead-connection，epoll的效率并不会比select/poll高很多，但是当遇到大量的idle-connection，就会发现epoll的效率大大高于select/poll。
为什么epoll比select和poll更高效？
（1）减少了用户态和内核态之间文件描述符的拷贝
select创建了3个文件描述符集（fd_set）并拷贝到内核中，分别监听读、写、异常事件。内核分配相关数据结构（fd_set_bits），内核在检测到有就绪事件后，就修改用户传进来的fd_set的值以告知用户有就绪的文件描述符。将文件描述符fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。内核删除和文件描述符相关的数据结构，由于内核修改了用户传进来的fd_set文件描述符集，下次调用select前必须要重置fd_set，然后重新传给内核，内核再重新拷贝一份，重新分配数据结构。
poll系统调用将struct_pollfd结构体数组拷贝到内核中进行监听，内核分配相关数据结构poll_list,用来存储监听的文件描述符，然后调用所有fd对应的poll(将current挂到各个fd对应的设备等待队列上)，内核在检测到有就绪事件后，就修改fd对应的revents的值用来告知用户有就绪的文件描述符，而events成员保持不变，因此下次调用poll时，应用程序无需重置pollfd类型的事件集参数。将之前传入的struct_pollfd结构体数组拷贝传出到用户态，并返回就绪文件描述符的总个数。内核删除和文件描述符相关的数据结构，下次调用poll需要将struct pollfd重新传给内核，内核在重新拷贝一份，重新分配数据结构。
epoll执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符)，接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核，内核会在红黑树上添加相应的结点，内核将就绪的文件描述符事件复制到传入的epoll_event结构体数组中返回给用户空间，系统调用在返回时采用mmap共享存储区，需要拷贝的次数大大减少。由于epoll创建的有关文件描述符的数据结构本身就存在于内核态中。下一次调用epoll系统调用时，不需要再次拷贝用户空间所要监听的文件描述符，也不需要重新构建红黑树和就绪链表等相关数据结构，直接沿用已经存在的数据结构。
（2）减少了对就绪文件描述符的遍历
select和poll采用轮询的方式来检查文件描述符是否处于就绪状态。并且内核修改用户传进来的fd_set和pollfd结构体的成员的revents值以告知用户有文件描述符就绪，但是用户并不知道有哪些文件描述符处于就绪态，需要遍历查找就绪文件描述符，因此，应用程序索引就绪文件描述符的时间复杂度为O（n）。而epoll采用回调机制。在调用epoll_ctl时，已经将用户感兴趣的事件传给了内核，内核会维持一个内核事件表，记录用户感兴趣的事件，就绪事件发生时，驱动设备调用回调函数ep_poll_callback()将就绪的fd挂到rdllist上。用户调用epoll_wait时，将rdllist上就绪的文件描述符发送给用户。此时发送给用户的都是就绪的fd。因此，应用程序索引就绪文件描述符的时间复杂度为O（1）。
（3）select和poll只支持LT模式，而epoll支持高效的ET模式，并且epoll还支持EPOLLONESHOT事件。
LT模式（电平触发）：LT模式是默认的工作模式，当检测到文件描述符上有事件发生并将此事件通知给应用程序，应用程序可以不立即处理该事件，下次调用会再次响应应用程序并通知此事件。
ET模式（边沿触发）：当检测到文件描述符上有事件发生并将此事件通知给应用程序，应用程序必须立即处理该事件，如果没处理或者没处理完，下次调用不会再响应应用程序并通知此事件。
ET模式很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高，epoll工作在ET模式的时候，必须使用非阻塞的套接字，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
注意即使使用ET模式，一个socket上的某个事件还是可能被触发多次，这在并发程序中就会引发一个问题。比如一个线程在读取完某个socket上的数据开始处理这些数据的时候，而在数据的处理过程中这个socket上又有新数据可读，这时另一个线程被唤醒来处理新数据，于是就出现了两个线程同时操作一个socket的局面。因此需要使用epoll的EPOLLONESHOT事件实现。对于注册了EPOLLONESHOT事件的文件描述符，操作系统最多触发其上的一个读、写或异常事件，且只触发一次。当一个线程在处理socket时，其它线程是不可能有机会操作该socket的。注册了EPOLLONESHOT事件的socket一旦被某个线程处理完，该线程就应该立即重置这个socket上的EPOLLONESHOT事件，以确保这个socket下次可读时，其EPOLLIN事件可被触发，进而让其它线程有机会处理这个socket。使用EPOLLONESHOT事件能进一步减少可读、可写和异常事件的被触发的次数。
无论哪种情况下，eopll都比select和poll高效吗？
epoll适用于连接较多，活动数量较少的情况。
(1)epoll为了实现返回就绪的文件描述符，维护了一个红黑树和好多个等待队列，内核开销很大。如果此时监听了很少的文件描述符，底层的开销会得不偿失；
(2)epoll中注册了回调函数，当有事件发生时，服务器设备驱动调用回调函数将就绪的fd挂在rdllist上，如果有很多的活动，同一时间需要调用的回调函数数量太多，服务器压力太大。
select和poll适用于连接较少的情况。
当select和poll上监听的fd数量较少，内核通知用户现在有就绪事件发生，应用程序判断当前是哪个fd就绪所消耗的时间复杂度就会大大减小。