提問一：
Linux IO多路復用有 epoll， poll， select，知道epoll性能比其他幾者要好。也在網上查了一下這幾者的區別，表示沒有弄明白。
IO多路復用是什么意思，在實際的應用中是指什么情況？
以及IO多路復用在一些異步web server中的實際應用，就好比nginx是怎樣使用epoll來實現異步IO處理的，一個請求到來了，nginx使用epoll接收請求的過程是怎樣的？
回答1
作者：羅志宇
這個還是很好說清楚的。
假設你是一個機場的空管， 你需要管理到你機場的所有的航線， 包括進港，出港， 有些航班需要放到停機坪等待，有些航班需要去登機口接乘客。
你會怎么做?
最簡單的做法，就是你去招一大批空管員，然后每人盯一架飛機， 從進港，接客，排位，出港，航線監控，直至交接給下一個空港，全程監控。
那么問題就來了：
- 很快你就發現空管塔里面聚集起來一大票的空管員，交通稍微繁忙一點，新的空管員就已經擠不進來了。
- 空管員之間需要協調，屋子里面就1， 2個人的時候還好，幾十號人以后 ，基本上就成菜市場了。
- 空管員經常需要更新一些公用的東西，比如起飛顯示屏，比如下一個小時后的出港排期，最后你會很驚奇的發現，每個人的時間最后都花在了搶這些資源上。
現實上我們的空管同時管幾十架飛機稀松平常的事情， 他們怎么做的呢？
他們用這個東西
這個東西叫flight progress strip。 每一個塊代表一個航班，不同的槽代表不同的狀態，然后一個空管員可以管理一組這樣的塊（一組航班），而他的工作，就是在航班信息有新的更新的時候，把對應的塊放到不同的槽子里面。
這個東西現在還沒有淘汰哦，只是變成電子的了而已。。
是不是覺得一下子效率高了很多，一個空管塔里可以調度的航線可以是前一種方法的幾倍到幾十倍。
如果你把每一個航線當成一個Sock(I/O 流)， 空管當成你的服務端Sock管理代碼的話。
- 第一種方法就是最傳統的多進程並發模型 (每進來一個新的I/O流會分配一個新的進程管理。)
- 第二種方法就是I/O多路復用 (單個線程，通過記錄跟蹤每個I/O流(sock)的狀態，來同時管理多個I/O流 。)
其實“I/O多路復用”這個坑爹翻譯可能是這個概念在中文里面如此難理解的原因。所謂的I/O多路復用在英文中其實叫 I/O multiplexing。 如果你搜索multiplexing啥意思，基本上都會出這個圖：
於是大部分人都直接聯想到"一根網線，多個sock復用" 這個概念，包括上面的幾個回答， 其實不管你用多進程還是I/O多路復用， 網線都只有一根。多個Sock復用一根網線這個功能是在內核＋驅動層實現的。
重要的事情再說一遍： I/O multiplexing 這里面的 multiplexing 指的其實是在單個線程通過記錄跟蹤每一個Sock(I/O流)的狀態(對應空管塔里面的Fight progress strip槽)來同時管理多個I/O流。
發明它的原因，是盡量多的提高服務器的吞吐能力。
是不是聽起來好拗口，看個圖就懂了。
在同一個線程里面， 通過撥開關的方式，來同時傳輸多個I/O流， (學過EE的人現在可以站出來義正嚴辭說這個叫“時分復用”了）。
什么，你還沒有搞懂“一個請求到來了，nginx使用epoll接收請求的過程是怎樣的”， 多看看這個圖就了解了。提醒下，ngnix會有很多鏈接進來， epoll會把他們都監視起來，然后像撥開關一樣，誰有數據就撥向誰，然后調用相應的代碼處理。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
了解這個基本的概念以后，其他的就很好解釋了。
select， poll， epoll 都是I/O多路復用的具體的實現，之所以有這三個鬼存在，其實是他們出現是有先后順序的。
I/O多路復用這個概念被提出來以后， select是第一個實現 (1983 左右在BSD里面實現的)。
select 被實現以后，很快就暴露出了很多問題。
- select 會修改傳入的參數數組，這個對於一個需要調用很多次的函數，是非常不友好的。
- select 如果任何一個sock(I/O stream)出現了數據，select 僅僅會返回，但是並不會告訴你是那個sock上有數據，於是你只能自己一個一個的找，10幾個sock可能還好，要是幾萬的sock每次都找一遍，這個無謂的開銷就頗有海天盛筵的豪氣了。
- select 只能監視1024個鏈接， 這個跟草榴沒啥關系哦，Linux 定義在頭文件中的，參見FD_SETSIZE。
- select 不是線程安全的，如果你把一個sock加入到select， 然后突然另外一個線程發現，尼瑪，這個sock不用，要收回。對不起，這個select 不支持的，如果你喪心病狂的竟然關掉這個sock， select的標准行為是。。呃。。不可預測的， 這個可是寫在文檔中的哦。
“If a file descriptor being monitored by select() is closed in another thread， the result is unspecified”
霸不霸氣
於是14年以后(1997年）一幫人又實現了poll， poll 修復了select的很多問題，比如
- poll 去掉了1024個鏈接的限制，於是要多少鏈接呢， 主人你開心就好。
- poll 從設計上來說，不再修改傳入數組，不過這個要看你的平台了，所以行走江湖，還是小心為妙。
其實拖14年那么久也不是效率問題， 而是那個時代的硬件實在太弱，一台服務器處理1千多個鏈接簡直就是神一樣的存在了，select很長段時間已經滿足需求。
但是poll仍然不是線程安全的， 這就意味着，不管服務器有多強悍，你也只能在一個線程里面處理一組I/O流。你當然可以那多進程來配合了，不過然后你就有了多進程的各種問題。
於是5年以后， 在2002， 大神 Davide Libenzi 實現了epoll。
epoll 可以說是I/O 多路復用最新的一個實現，epoll 修復了poll 和select絕大部分問題， 比如：
- epoll 現在是線程安全的。
- epoll 現在不僅告訴你sock組里面數據，還會告訴你具體哪個sock有數據，你不用自己去找了。
epoll 當年的patch，現在還在，下面鏈接可以看得到：
貼一張霸氣的圖，看看當年神一樣的性能（測試代碼都是死鏈了， 如果有人可以刨墳找出來，可以研究下細節怎么測的)。
橫軸Dead connections 就是鏈接數的意思，叫這個名字只是它的測試工具叫deadcon。 縱軸是每秒處理請求的數量，你可以看到，epoll每秒處理請求的數量基本不會隨着鏈接變多而下降的。poll 和/dev/poll 就很慘了。
可是epoll 有個致命的缺點。。只有linux支持。比如BSD上面對應的實現是kqueue。
其實有些國內知名廠商把epoll從安卓里面裁掉這種腦殘的事情我會主動告訴你嘛。什么，你說沒人用安卓做服務器，尼瑪你是看不起p2p軟件了啦。
而 ngnix 的設計原則里面， 它會使用目標平台上面最高效的I/O多路復用模型咯，所以才會有這個設置。一般情況下，如果可能的話，盡量都用epoll/kqueue吧。
詳細的在這里：
PS： 上面所有這些比較分析，都建立在大並發下面，如果你的並發數太少，用哪個，其實都沒有區別。 如果像是在歐朋數據中心里面的轉碼服務器那種動不動就是幾萬幾十萬的並發，不用epoll我可以直接去撞牆了。
回答2：
要弄清問題 先要知道問題的出現原因
原因：
由於進程的執行過程是線性的(也就是順序執行)，當我們調用低速系統I/O(read，write，accept等等)，進程可能阻塞，此時進程就阻塞在這個調用上，不能執行其他操作。阻塞很正常。 接下來考慮這么一個問題：
一個服務器進程和一個客戶端進程通信，服務器端read(sockfd1，bud，bufsize)，此時客戶端進程沒有發送數據，那么read(阻塞調用)將阻塞直到客戶端調用write(sockfd，but，size)發來數據。 在一個客戶和服務器通信時這沒什么問題，當多個客戶與服務器通信時，若服務器阻塞於其中一個客戶sockfd1，當另一個客戶的數據到達套接字sockfd2時，服務器不能處理，仍然阻塞在read(sockfd1。。。)上；此時問題就出現了，不能及時處理另一個客戶的服務，咋么辦？I/O多路復用來解決！
I/O多路復用：
繼續上面的問題，有多個客戶連接，sockfd1，sockfd2，sockfd3。。sockfdn同時監聽這n個客戶，當其中有一個發來消息時就從select的阻塞中返回，然后就調用read讀取收到消息的sockfd，然后又循環回select阻塞;
這樣就不會因為阻塞在其中一個上而不能處理另一個客戶的消息
提問二：I/O復用 與 連接池 的區別
答主你好，看你的回答好犀利，我菜鳥一個好多概念搞不清楚，想請教你一些。I/O復用是不是用跟各種池一起用的？比如線程池，socket連接池哪些。最困擾的一個問題是一個線程池或socket連接池里面的諸多線程、socket如何利用一個端口與多個端進行通信的呢？還有您能不能能說一下一個socket連接池里面的諸多socket有何不同啊，是不是就只是目的IP和目的端口的區別？萬謝！！！
回答1：
線程池和socket池都和具體實現有關。所以你要告訴我你指的線程池是某個實現呢，還是通常意義上的“線程池”
通常意義上的線程池只是多線程里面對線程生命周期的一個管理方法而已（不用的線程不是直接結束掉，而是放到池里面復用，以避免創建／銷毀線程的開銷），和並發模型沒有關系。線程池＝空管員宿舍。沒有宿舍，空管員都要從家里來上班，有了宿舍，上下班開銷變小。但是和空管們工作方式沒有關系。
不過很多很多的文章里面說的線程池其實是和多線程模型一起用的（多進程模型里面把進程換成線程）。這種情況一般是一個線程一個socket。
如果用I/O復用和線程池，一般是一個線程一組I/O， 然后可能另外還有一堆工作線程處理具體數據。
關於socket 一個端口和多個端口通信如何通信？你注意到了accept會返回一個新的socket描述符么。所以服務端只會監聽一個端口，每次來了新的請求，都會創建一個新的socket和客戶端通信。
每個socket就是一個I/O流，不考慮協議的情況下，確實就是兩端IP和端口不同（服務器可能有多個IP)。 不管這個socket在不在池里面。
摘自：