Epoll为什么比select高效

1、select的原理
首先select在处理多客户端接受数据的问题上是这样处理的的，首先将要坚挺的socket添加到一个fs_set[]数组中，然后将在select时候将这些监听的socket传递给内核(这些socket在内核中表示为一个文件，这个文件对应有他的socket buffer用于存放接收发送数据)，如果此时这些监听的socket上有数据了，则直接返回.否则则会将这个进程后者线程阻塞(这里阻塞的实现是将这个进程或者线程添加到这个socket(文件或者设备)的等待队列中，也就是将这个进程从CPU的工作队列添加等待队列中)，因为是监听了很多的socket，同时这些socket有没有一个统一管理和维护的地方，因此每个socket都会维护这个socket对应的这个调用select的进程或者线程关系，每个socket都会将这个socket和这个线程关联起来，并且把各自的进程或者线程告诉操作系统，将其挂起，也就是从CPU的工作队列中移动到等待队列中。这样当前select的进程就不会被CPU调度到。如果此时网卡接受到数据，数据从网卡拷贝到内核中，这些数据中包含了端口号，所以知道这些数据来自那个socket.这样就知道这个socket接受到数据了，此时就把这个socket对应的那个进程唤醒(此时其实就是select函数返回)，但是这里还有一步动作就是其他socket也把这个进程挂在他们的等待队列中，所以这里需要遍历所有的 socket通知他们也把自己的对应的那个等待进程挂到运行队列中去。此时用户态select地方被返回。但是此时用户态进程或者线程却并不知道是那个socket上有数据，因此在select后还需要从fs_set[]数组中遍历确定是那个socket有数据，然后在在这个socet上调用recv接口接收数据。接收完数据后，又重新调用select接口重新循环刚刚上面描述的动作。
这个过程存在一些问题：
1、每次调用select都需要拷贝fd_set从用户态到内核态。
2、内核太监控到sockect返回，但是用户态需要遍历fd才能知道那些socket有数据，需要遍历，效率很低。
3、内核态需要遍历所有的socket摘除等待链表上的进程，遍历代价太大。
4、正是因为遍历的原因，所以内核设置了最大监听1024个socket的缘故，否则销量太低了。
二、epoll解决select的问题
所以epoll就是来解决select的问题的，首先epoll不会每次把监听的socket通过系统调用传递(拷贝)到内核态，而是在epoll_wait之前通过epoll_ctrl把需要监听的 socket添加到epoll_fd上去管理和维护.这个epoll_fd是通过epoll_create创建的，这里和select一个区别就是epoll多了一个epoll_fd来管理监听的socket。这个epoll_fd也是传递给内核态，然后将用户态需要监听socket添加到这个epoll_fd的一个红黑树上，这里使用红黑树的目的是需要查找，删除，添加销量高，这样在调用epoll_wait期间都可以很高效的增删监听的socket.和select不一样的是调用epoll_wait如果这个红黑树上的socket上有数据就返回，否则就把进程或者线程阻塞，这里的阻塞只会将这个进程和这个epoll_fd帮顶起来，也就是把这个进程挂在这个epoll_fd文件(设备)的等待队列上。同时这个epoll_fd还维护一个readylist（一个双向链表），只要红黑树上的 socket有数据就将这个socket挂在read list上去，然后通知epoll_fd将对应的进程唤醒，添加到CPU运行队列中。这样用户态的进程调用epoll_wait地方继续执行，这里还有一点需要说明的是，下面ready list上的socket会通过epoll_wait调用时候传递来一个epoll_event数组拷贝会用户态，并且socket个数就是epoll_wait返回值返回的。这样用户态的进程既可以通过epoll_wait返回值和epoll_event[]数组中的socketfd就行数据的接收处理了。

三、总结
epoll对与select多了一个event_fd来管理所有的socket.而且一直内核态监听中，但是select没有这个东西，所以需要每次传递到内核态，这样效率就很低小。