轉自：https://www.zhihu.com/question/32163005

1 IO 多路複用是什麼意思？ - 羅志宇的回答 - 知乎 https://www.zhihu.com/question/32163005/answer/55772739

這個還是很好說清楚的。

假設你是一個機場的空管， 你需要管理到你機場的所有的航線， 包括進港，出港， 有些航班需要放到停機坪等待，有些航班需要去登機口接乘客。

你會怎麼做?

最簡單的做法，就是你去招一大批空管員，然後每人盯一架飛機， 從進港，接客，排位，出港，航線監控，直至交接給下一個空港，全程監控。

那麼問題就來了：

• 很快你就發現空管塔裡面聚集起來一大票的空管員，交通稍微繁忙一點，新的空管員就已經擠不進來了。
• 空管員之間需要協調，屋子裡面就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，現在還在，下面連結可以看得到：
/dev/epoll Home Page

貼一張霸氣的圖，看看當年神一樣的效能（測試程式碼都是死鏈了， 如果有人可以刨墳找出來，可以研究下細節怎麼測的).

橫軸Dead connections 就是連結數的意思，叫這個名字只是它的測試工具叫deadcon. 縱軸是每秒處理請求的數量，你可以看到，epoll每秒處理請求的數量基本不會隨著連結變多而下降的。poll 和/dev/poll 就很慘了。

可是epoll 有個致命的缺點。。只有linux支援。比如BSD上面對應的實現是kqueue。

其實有些國內知名廠商把epoll從安卓裡面裁掉這種腦殘的事情我會主動告訴你嘛。什麼，你說沒人用安卓做伺服器，尼瑪你是看不起p2p軟體了啦。

而ngnix 的設計原則裡面， 它會使用目標平臺上面最高效的I/O多路複用模型咯，所以才會有這個設定。一般情況下，如果可能的話，儘量都用epoll/kqueue吧。

詳細的在這裡:
Connection processing methods

PS: 上面所有這些比較分析，都建立在大併發下面，如果你的併發數太少，用哪個，其實都沒有區別。 如果像是在歐朋資料中心裡面的轉碼伺服器那種動不動就是幾萬幾十萬的併發，不用epoll我可以直接去撞牆了。

I/O複用是不是用跟各種池一起用的？

執行緒池和sock池都和具體實現有關。所以你要告訴我你指的執行緒池是某個實現呢，還是通常意義上的“執行緒池”

通常意義上的執行緒池只是多執行緒裡面對執行緒生命週期的一個管理方法而已（不用的執行緒不是直接結束掉，而是放到池裡面複用， 以避免建立／銷燬執行緒的開銷），和併發模型沒有關係。執行緒池＝空管員宿舍。沒有宿舍，空管員都要從家裡來上班，有了宿舍，上下班開銷變小。但是和空管們工作方式沒有關係。

不過很多很多的文章裡面說的執行緒池其實是和多執行緒模型一起用的（多程序模型裡面把程序換成執行緒）。這種情況一般是一個執行緒一個sock.

如果用I/O複用和執行緒池，一般是一個執行緒一組I/O, 然後可能另外還有一堆工作執行緒處理具體資料。。

關於socket 一個埠和多個埠通訊如何通訊？你注意到了accept會返回一個新的socket描述符麼。。所以服務端只會監聽一個埠，每次來了新的請求，都會建立一個新的sock和客戶端通訊。

每個socket就是一個I/O流，不考慮協議的情況下，確實就是兩端IP和埠不同（伺服器可能有多個IP). 不管這個socket在不在池裡面。

筆者菠蘿關於多執行緒和io多路複用的一點看法

見下篇