select /poll/ epoll 对比

单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，

select不足的地方：

1 每次select都要把全部IO句柄复制到内核

2 内核每次都要遍历全部IO句柄，以判断是否数据准备好

3 select模式最大IO句柄数是1024，太多了性能下降明显

poll：

poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在_FD_SETSIZE为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

epoll的特点

1 每次新建IO句柄(epoll_create)才复制并注册(epoll_register)到内核

2 内核根据IO事件，把准备好的IO句柄放到就绪队列

3 应用只要轮询(epoll_wait)就绪队列，然后去读取数据

只需要轮询就绪队列（数量少），不存在select的轮询，也没有内核的轮询，不需要多次复制所有的IO句柄。因此，可以同时支持的IO句柄数轻松过百万。