为什么select和poll不如epoll？

select的工作方式是
1. 创建一个socket列表，在这个列表中添加想要监听的socket对象的文件描述符
2. 在调用select函数的时候，操作系统将当前进程加入到列表中所有socket对象的等待队列中(每个socket都有一个等待队列)
3. 如果有一个socket接受到了数据的处理流程，那么进程将会被唤醒。唤醒的过程中会将当前进程从所有socket的等待队列中移除。
4. 此时进程知道至少有一个socket对象接受到了数据，然后程序通过遍历一遍socket列表中的所有socket的对象，就可以得到就绪的socket对象。(图片来自转载)

所以select的缺点在于
1 每次调用select都需要将文件描述符复制给内核
2 每次需要将进程添加到所有的socket对象的等待队列中
3 每次唤醒都需要将进程从所有socket对象的等待队列中删除
4 需要遍历一遍socket列表才能知道哪些socket发生了事件

一共经历了三次循环，一次复制，socket对象数量越多消耗越大。
所以poll虽然突破了文件描述符的上限，但是在性能上还是有所欠缺。
 

epoll引入一个epollevent作为中间件管理用户的事件，进程只和epollevent进行通信，和各个socket对象没有交集。
n * socket  <==> epollevent   <==> 进程
所以当socket对象准备好了一个数据后，并不会立刻唤醒进程，而只是添加到epollevent的就绪队列中。
在epollevent的等待队列中添加进程，然后再通过epoll_ctl函数将epollevent添加到对应的socket对象的等待队列中。

在socket对象发生事件后，将这个socket的引用添加到epollevent的就绪队列中。
调用epoll_wait函数后只需要看epollevent的就绪队列中是否有socket对象发生了事件，如果有则唤醒进程然后对各个时间进行处理,如果没有则阻塞。
程序被唤醒后，只需要执行epollevent的就绪队列中的所有socket对象的事件就可以了，而无需通过遍历寻找发生事件的socket对象，因为所有在就绪队列中的socket对象一定是发生了事件的socket对象。

如有疑问可以观看知乎大佬图文并茂的epoll讲解，看不懂的去砍他 - 叨陪鲤 - 博客园，里面有很详细的描述，讲的非常清晰。