select，poll，epoll都是IO多路復用的機制。I/O多路復用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作。

select，poll，epoll本質上都是同步I/O，因為他們都需要在讀寫事件就緒后自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而異步I/O則無需自己負責進行讀寫，異步I/O的實現會負責把數據從內核拷貝到用戶空間。

select的幾大缺點：

一、select

select本質上是通過設置或者檢查存放fd標志位的數據結構來進行下一步處理。這樣所帶來的缺點是：

1、select文件描述符數量太小

select最大的缺陷就是單個進程所打開的FD是有一定限制的，它由FD_SETSIZE設置，默認值是1024。

一般來說這個數目和系統內存關系很大，具體數目可以cat /proc/sys/fs/file-max察看。32位機默認是1024個，64位機默認是2048。

2、輪詢

對socket進行掃描時是線性掃描，即采用輪詢的方法，效率較低。

當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。

3、復制fd開銷大

需要維護一個用來存放大量fd的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時復制開銷大。

（1）每次調用select，都需要把fd集合從用戶態拷貝到內核態，這個開銷在fd很多時會很大

（2）同時每次調用select都需要在內核遍歷傳遞進來的所有fd，這個開銷在fd很多時也很大

單個進程能夠監視的文件描述符的數量存在最大限制，通常是1024，當然可以更改數量，但由于select采用輪詢的方式掃描文件描述符，文件描述符數量越多，性能越差；(在linux內核頭文件中，有這樣的定義：#define __FD_SETSIZE 1024)

內核 / 用戶空間內存拷貝問題，select需要復制大量的句柄數據結構，產生巨大的開銷；

select返回的是含有整個句柄的數組，應用程序需要遍歷整個數組才能發現哪些句柄發生了事件；

select的觸發方式是水平觸發，應用程序如果沒有完成對一個已經就緒的文件描述符進行IO操作，那么之后每次select調用還是會將這些文件描述符通知進程。

二、poll

poll的實現和select非常相似，只是描述fd集合的方式不同，poll使用pollfd結構而不是select的fd_set結構，其他的都差不多。

poll將用戶傳入的數組拷貝到內核空間，然后查詢每個fd對應的設備狀態，如果設備就緒則在設備等待隊列中加入一項并繼續遍歷，如果遍歷完所有fd后沒有發現就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒后它又要再次遍歷fd。這個過程經歷了多次無謂的遍歷。

它沒有最大連接數的限制，原因是它是基于鏈表來存儲的，但是同樣有一個缺點：
1）大量的fd的數組被整體復制于用戶態和內核地址空間之間，而不管這樣的復制是不是有意義。
2）poll還有一個特點是“水平觸發”，如果報告了fd后，沒有被處理，那么下次poll時會再次報告該fd。

三、epoll

epoll是Linux多路服用IO接口select/poll的加強版，e對應的英文單詞就是enhancement，中文翻譯為增強，加強，提高，充實的意思。所以epoll模型會顯著提高程序在大量并發連接中只有少量活躍的情況下的系統CPU利用率。

epoll支持水平觸發和邊緣觸發，最大的特點在于邊緣觸發，它只告訴進程哪些fd剛剛變為就緒態，并且只會通知一次。

epoll使用“事件”的就緒通知方式，通過epoll_ctl注冊fd，一旦該fd就緒，內核就會采用類似callback的回調機制來激活該fd，epoll_wait便可以收到通知。

epoll把用戶關心的文件描述符上的時間放在內核的一個事件表中，無需像select和poll那樣每次調用都重復傳入文件描述符集。

epoll在獲取事件的時候，無需遍歷整個被監聽的文件描述符集合，而是遍歷那些被內核IO事件異步喚醒而加入ready隊列的描述符集合。

epoll既然是對select和poll的改進，那epoll是怎么解決的呢？在此之前，我們先看一下epoll和select和poll的調用接口上的不同，select和poll都只提供了一個函數——select或者poll函數。

epoll的設計和實現與select完全不同。epoll通過在Linux內核中申請一個簡易的文件系統(文件系統一般用什么數據結構實現？B+樹)。把原先的select/poll調用分成了3個部分：

1）調用epoll_create()建立一個epoll對象(在epoll文件系統中為這個句柄對象分配資源)

2）調用epoll_ctl向epoll對象中添加這100萬個連接的套接字

3）調用epoll_wait收集發生的事件的連接

針對復制開銷，epoll的解決方案在epoll_ctl函數中。每次注冊新的事件到epoll句柄中時（在epoll_ctl中指定EPOLL_CTL_ADD），會把所有的fd拷貝進內核，而不是在epoll_wait的時候重復拷貝。epoll保證了每個fd在整個過程中只會拷貝一次。

對于輪詢問題，epoll的解決方案不像select或poll一樣每次都把current輪流加入fd對應的設備等待隊列中，而只在epoll_ctl時把current掛一遍（這一遍必不可少）并為每個fd指定一個回調函數，當設備就緒，喚醒等待隊列上的等待者時，就會調用這個回調函數，而這個回調函數會把就緒的fd加入一個就緒鏈表）。epoll_wait的工作實際上就是在這個就緒鏈表中查看有沒有就緒的fd（利用schedule_timeout()實現睡一會，判斷一會的效果，和select實現中的第7步是類似的）。

針對數量限制，epoll沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大于2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關系很大。

四、總結

（1）select，poll實現需要自己不斷輪詢所有fd集合，直到設備就緒，期間可能要睡眠和喚醒多次交替。而epoll其實也需要調用epoll_wait不斷輪詢就緒鏈表，期間也可能多次睡眠和喚醒交替，但是它是設備就緒時，調用回調函數，把就緒fd放入就緒鏈表中，并喚醒在epoll_wait中進入睡眠的進程。雖然都要睡眠和交替，但是select和poll在“醒著”的時候要遍歷整個fd集合，而epoll在“醒著”的時候只要判斷一下就緒鏈表是否為空就行了，這節省了大量的CPU時間。這就是回調機制帶來的性能提升。

（2）select，poll每次調用都要把fd集合從用戶態往內核態拷貝一次，并且要把current往設備等待隊列中掛一次，而epoll只要一次拷貝，而且把current往等待隊列上掛也只掛一次（在epoll_wait的開始，注意這里的等待隊列并不是設備等待隊列，只是一個epoll內部定義的等待隊列）。這也能節省不少的開銷。

如此一來，要實現上面說是的場景，只需要在進程啟動時建立一個epoll對象，然后在需要的時候向這個epoll對象中添加或者刪除連接。同時，epoll_wait的效率也非常高，因為調用epoll_wait時，并沒有一股腦的向操作系統復制這100萬個連接的句柄數據，內核也不需要去遍歷全部的連接。

參考

1、select、poll、epoll之間的區別總結[整理]
2、IO多路復用之select、poll、epoll詳解
3、深度理解select、poll和epoll(含有實現代碼)
4、select、poll、epoll的比較-select輪詢+sleep,epoll異步事件驅動高效
5、linux中的輪詢機制select/poll/epoll
6、libevent高性能網絡庫源碼分析——Reactor模式（二）
7、libevent學習筆記 一、基礎知識
8、網絡編程中Reactor與Proactor的概念及區別
9、IO設計模式：Reactor和Proactor對比
10、libevent和基于libevent的網絡編程
11、兩種高性能I/O設計模式(Reactor/Proactor)的比較
12、兩種高效的事件處理模型：Reactor模式和Proactor模式
13、Linux網絡編程---I/O復用模型之epoll
14、epoll模型和使用詳解（精髓）epoll - I/O event notification facility
15、樸素、Select、Poll和Epoll網絡編程模型實現和分析——模型比較