1、select
select本質上是通過設置或者檢查存放fd標誌位的數據結構來進行下一步處理。
缺點：
1） 單個進程可監視的fd數量被限制。
2） 需要維護一個用來存放大量fd的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時複製開銷大。
3） 對fd進行掃描時是線性掃描。fd劇增後，IO效率較低，因爲每次調用都對fd進行線性掃描遍歷，所以隨着fd的增加會造成遍歷速度慢的性能問題
4）select() 函數的超時參數在返回時也是未定義的，考慮到可移植性，每次在超時之後在下一次進入到select之前都需要重新設置超時參數。
優點：
1）select()的可移植性更好，在某些Unix系統上不支持poll()
2）select() 對於超時值提供了更好的精度：微秒，而poll是毫秒。
2、poll
poll本質上和select沒有區別，它將用戶傳入的數組拷貝到內核空間，然後查詢每個fd對應的設備狀態，如果設備就緒則在設備等待隊列中加入一項並繼續遍歷，如果遍歷完所有fd後沒有發現就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒後它又要再次遍歷fd。這個過程經歷了多次無謂的遍歷。poll還有一個特點是“水平觸發”，如果報告了fd後，沒有被處理，那麼下次poll時會再次報告該fd。
缺點：
1）大量的fd的數組被整體複製於用戶態和內核地址空間之間，而不管這樣的複製是不是有意義。
2）與select一樣，poll返回後，需要輪詢pollfd來獲取就緒的描述符
優點：
1）poll() 不要求開發者計算最大文件描述符加一的大小。
2）poll() 在應付大數目的文件描述符的時候速度更快，相比於select。
3）它沒有最大連接數的限制，原因是它是基於鏈表來存儲的。
3、epoll
epoll支持水平觸發和邊緣觸發，最大的特點在於邊緣觸發，它只告訴進程哪些fd剛剛變爲就需態，並且只會通知一次。還有一個特點是，epoll使用“事件”的就緒通知方式，通過epoll_ctl註冊fd，一旦該fd就緒，內核就會採用類似callback的回調機制來激活該fd，epoll_wait便可以收到通知。
優點：
1）支持一個進程打開大數目的socket描述符(FD)
select最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是1024/2048。對於那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關係很大。
2）IO效率不隨FD數目增加而線性下降
傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因爲在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket纔會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"僞"AIO，因爲這時候推動力在Linux內核。
3）使用mmap加速內核與用戶空間的消息傳遞。
這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核與用戶空間mmap同一塊內存實現的。
4、三者的比較
