select,poll,epoll只须要看这一篇就行了

select、poll、epoll：select，poll，epoll都是IO多路复用的机制

select，poll，epoll本质上都是同步I/O，由于他们都须要在读写事件就绪后本身负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需本身负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。epoll跟select都能提供多路I/O复用的解决方案。在如今的Linux内核里有都可以支持，其中epoll是Linux所特有，而select则通常操做系统均有实现。

一、没有最大并发链接的限制，能打开的FD(file descriptor:文件描述符)的上限远大于1024（1G的内存上能监听约10万个端口）；

二、效率提高，不是轮询的方式，不会随着FD数目的增长效率降低。只有活跃可用的FD才会调用callback函数；

即Epoll最大的优势就在于它只管你“活跃”的链接，而跟链接总数无关，所以在实际的网络环境中，Epoll的效率就会远远高于select和poll。

select有三个缺点：

一、链接数受限

二、查找匹配速度慢

三、数据由内核拷贝到用户态

poll改善了第一个缺点，epoll改善了三个缺点。

(1)select==>时间复杂度O(n)

它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至所有），咱们只能无差异轮询全部流，找出能读出数据，或者写入数据的流，对他们进行操做。因此select具备O(n)的无差异轮询复杂度，同时处理的流越多，无差异轮询时间就越长。

(2)poll==>时间复杂度O(n)

poll本质上和select没有区别，它将用户传入的数据拷贝到内核空间，而后查询每一个fd对应的设备状态， 可是它没有最大链接数的限制，缘由是它是基于链表来存储的.由于每次调用时都会对链接进行线性遍历，因此随着FD的增长会形成遍历速度慢的“线性降低性能问题”。

(3)epoll==>时间复杂度O(1)

epoll能够理解为event poll，不一样于忙轮询和无差异轮询，epoll会把哪一个流发生了怎样的I/O事件通知咱们。因此咱们说epoll其实是事件驱动（每一个事件关联上fd）的，此时咱们对这些流的操做都是有意义的。（复杂度下降到了O(1)）

总结：

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特色。

一、表面上看epoll的性能最好，可是在链接数少而且链接都十分活跃的状况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制须要不少函数回调。

二、select低效是由于每次它都须要轮询。但低效也是相对的，视状况而定，也可经过良好的设计改善