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低效是由於每次它都須要輪詢。但低效也是相對的，視狀況而定，也可經過良好的設計改善