epoll比select高效的原因及select比epoll高效场景

epoll高效的原因，从下面几个方向来说：

1. 用户态将文件描述符传入内核的方式

select：

select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);

根据API，可以看出select需要提供三个文件描述符（内部是位图，所以只用三个即可），分别监听读、写、异常。

epoll：

epoll_create的时候在内核高速cache中建红黑树以及就绪链表（存储已有监听事件到达的fd）。用户执行epoll_ctl的时候就会在红黑树中增加相应的节点。

2. 内核监测文件描述符是否可读可写的方式

select:

采取轮询的方式，遍历fd，最后返回一个描述符读写操作是否就绪的mask掩码，根据这个掩码给fd_set赋值。

epoll：

通过在epoll_ctl的时候想内核注册回调函数，内核在监测到文件描述符可读/可写的时候调用相应的回调，将文件描述符相关的结构体放入就绪链表中。

3. 如何找到就绪的文件描述符并传递给用户

select：

用户并不知道哪些文件描述符处于就绪状态，需要遍历。

epoll：

epoll_wait的时候直接检查就绪链表，返回的fd都是已经就绪的，以此处理即可。

4. 继续重新监听时如何重复以上步骤

select:

将新的文件描述符重新传入内核态中，需要重新复制一次。

epoll：

无须重新传入，直接沿用红黑树中节点即可。

5. 在什么情况下select会比epoll高效呢

在少连接高并发的情况下。

因为，连接少意味着不会超过select1024的上限，高并发意味着一次wait每一个连接都会来数据。把扫描有事件连接时的O(n)的复杂度降至O(1)。

加上每次只需要复制4次fd_set从内核空间和用户空间往返，(sizeof(fd_set)=128)，总体上比epoll要复制的量要少(sizeof(struct epoll_event)=12)(假设100个连接 12*100=1200)。在这种情况下select是要比epoll高效的。

到这里延伸一下，如果select支持大量连接，并且每一个连接都是相当活跃的，即还是O(n)->O(1)的情况。那么select的性能要比epoll高。

也就是说select的差距主要体现在每次内核O(n)的去遍历fd，用户也需要去遍历fd，造成效率低下。