前言
你知?.NETty為什么性能這么高嗎？你知道redis為什么單線程如此之快嗎？這都和底層的網(wǎng)絡IO模型有關系，所以掌握網(wǎng)絡IO模型真的很重要，是一個基礎，對你更好的理解其他應用幫助非常大，今天我們就好好來聊聊linux的5種網(wǎng)絡IO模型。
IO工作原理
我們的應用大多數(shù)情況都是部署在linux系統(tǒng)中，linux系統(tǒng)也是一種應用，它是基于計算機硬件的一種操作系統(tǒng)軟件。當我們接收一次網(wǎng)絡傳輸，計算機硬件的網(wǎng)卡會從網(wǎng)絡中將讀到的字節(jié)流寫到linux的buffer緩沖區(qū)內存中，然后用戶空間會調用linux對外暴露的接口，將linux內核空間buffer內存中的數(shù)據(jù)拷貝到用戶空間的buffer區(qū)。這一次網(wǎng)絡讀取就是磁盤IO，同理從磁盤中讀取，也是遵循一樣的機制。
IO的性能瓶頸主要是下面兩個階段：
- 準備階段，指數(shù)據(jù)從網(wǎng)絡網(wǎng)卡或本地存儲器讀取到內核的過程
- 復制階段，指將內核緩沖區(qū)中的數(shù)據(jù)拷貝至用戶態(tài)的進程緩沖區(qū)
所以，Linux系統(tǒng)中提供了五種IO模型來提高性能，它們分別為BIO、NIO、多路復用、信號驅動、AIO，從性能上來說，它們屬于依次遞進的關系，但越靠后的IO模型實現(xiàn)也越為復雜。
1. 阻塞IO模型BIO
當用戶應用線程調用linux操作系統(tǒng)的recvfrom?函數(shù)讀取數(shù)據(jù)的時候，如果內核的buffer?內存中沒有數(shù)據(jù)，那么用戶線程會阻塞等待，直到內核的buffer?內存中有數(shù)據(jù)了，才去將內核的buffer內存中的數(shù)據(jù)拷貝到用戶應用內存中。
打比方理解：
比如你給女神發(fā)一條短信, 說我來找你了, 然后就默默的一直等著女神下樓, 這個期間除了等待你不會做其他事情, 屬于備胎做法。也就是說線程會一直阻塞等待內核把數(shù)據(jù)準備好，然后將數(shù)據(jù)copy到用戶空間。
優(yōu)點：
- 開發(fā)簡單，容易入門；
- 在阻塞等待期間，用戶線程掛起，在掛起期間不會占用CPU資源。
缺點：
- 在BIO這種模型中，為了支持并發(fā)請求，通常會采用多線程的方式，并發(fā)過高時會導致創(chuàng)建大量線程，造成頻繁的上下文切換，甚至系統(tǒng)崩潰
在JAVA常用的Tomcat服務器中，Tomcat7.x版本以下默認的IO類型也是BIO，但是Tomcat中對BIO模型稍微進行了優(yōu)化，通過線程池做了限制，所以避免出現(xiàn)并發(fā)過高而系統(tǒng)崩潰的情況。
2. 非阻塞IO模型NIO
當用戶應用線程調用linux操作系統(tǒng)的recvfrom?函數(shù)讀取數(shù)據(jù)的時候，如果內核的buffer?內存中沒有數(shù)據(jù)，那么用戶線程會直接拿到結果（沒有數(shù)據(jù)）不會阻塞等待，于是又會發(fā)起一次recvfrom函數(shù)調用，直到內核的buffer內存中有數(shù)據(jù)了，才去將內核的buffer內存中的數(shù)據(jù)拷貝到用戶應用內存中。
在非阻塞IO模型中，用戶線程需要不斷地詢問內核數(shù)據(jù)是否就緒，也就說非阻塞IO不會交出CPU，而會一直占用CPU。
打比方理解：
比如你給女神發(fā)短信, 如果不回, 接著再發(fā), 一直發(fā)到女神下樓, 這個期間你除了發(fā)短信等待不會做其他事情, 屬于專一做法。同理，用戶線程無需等待內核數(shù)據(jù)準備結果，直接返回，然后通過輪詢去問結果，如果結果為準備好，進程把數(shù)據(jù)copy到用戶空間。
優(yōu)點：
- 每次發(fā)起IO調用，在內核等待數(shù)據(jù)的過程中可以立即返回，用戶線程不會阻塞。
缺點：
- 多個線程不斷輪詢內核是否有數(shù)據(jù)，會占用大量CPU時間。
NIO相對來說較為雞肋，因此目前大多數(shù)的NIO技術并非采用這種多線程的模型，而是基于單線程的多路復用模型實現(xiàn)的，Java中支持的NIO模型亦是如此。
3. 多路復用IO模型
前面提到NIO由于線程在不斷的輪詢查看數(shù)據(jù)是否準備就緒，造成CPU開銷較大。既然說是由于大量無效的輪詢造成CPU占用過高，那么等內核中的數(shù)據(jù)準備好了之后，再去詢問數(shù)據(jù)是否就緒是不是就可以了？答案是Yes。這就是我們多路復用IO模型的設計思想。
多路復用IO模型是基于文件描述符File Descriptor?實現(xiàn)的，文件描述符是打開現(xiàn)存文件或新建文件時，內核會返回一個文件描述符。讀寫文件也需要使用文件描述符來指定待讀寫的文件。文件包含音頻文件，常規(guī)文件，硬件設備等等，也包括網(wǎng)絡套接字（Socket）。
IO多路復用就是利用Linux的內核單線程去監(jiān)聽多個文件描述符，并在某個文件描述符可讀、可寫的時候接收到通知，避免無效的等待，充分利用CPU資源。
關于監(jiān)聽的策略，在linux中提供了3種模式，也就是3個函數(shù)，分別是 select、poll、epoll，如下圖所示。
- select?時間復雜度O(n)，它僅僅知道了，有I/O事件發(fā)生了，卻并不知道是哪幾個流（可能有一個，多個，甚至全部），我們只能無差別輪詢所有流，找出能讀出數(shù)據(jù)，或者寫入數(shù)據(jù)的流，對他們進行操作。所以select具有O(n)的無差別輪詢復雜度，同時處理的流越多，無差別輪詢時間就越長，而且最多支持的連接數(shù)量是1024個。
- poll?（翻譯：輪詢）時間復雜度O(n)，poll本質上和select沒有區(qū)別，它將用戶傳入的數(shù)組拷貝到內核空間，然后查詢每個fd對應的設備狀態(tài)， 但是它沒有最大連接數(shù)的限制，原因是它是基于鏈表來存儲的。
- epoll?時間復雜度O(1)，epoll可以理解為event poll，不同于忙輪詢和無差別輪詢，epoll會把哪個流發(fā)生了怎樣的I/O事件通知我們。所以我們說epoll實際上是事件驅動（每個事件關聯(lián)上fd）的，此時我們對這些流的操作都是有意義的。（復雜度降低到了O(1)）。
打個比方理解：
IO多路復用相當于找一個宿管大媽來幫你監(jiān)視下樓的女生, 這個期間你可以些其他的事情. 例如可以順便看看其他妹子,玩玩王者榮耀, 上個廁所等等。IO復用又包括 select、poll、epoll 模式。那么它們的區(qū)別是什么?
- select?大媽 每一個女生下樓, select大媽都不知道這個是不是你的女神, 她需要一個一個詢問, 并且select大媽能力還有限, 最多一次幫你監(jiān)視1024個妹子。
- poll大媽不限制盯著女生的數(shù)量, 只要是經(jīng)過宿舍樓門口的女生, 都會幫你去問是不是你女神。
- epoll大媽不限制盯著女生的數(shù)量, 并且也不需要一個一個去問. 那么如何做呢? epoll大媽會為每個進宿舍樓的女生臉上貼上一個大字條,上面寫上女生自己的名字, 只要女生下樓了, epoll大媽就知道這個是不是你女神了, 然后大媽再通知你。
通知你之后，你需要到女生宿舍門口，把女神帶回自己宿色。
優(yōu)點：
- 系統(tǒng)不必創(chuàng)建維護大量線程，只使用一個線程，一個選擇器即可同事處理成千上萬個連接，大大減少系統(tǒng)開銷。
缺點：
- 本質上，它還是同步的，數(shù)據(jù)準備好后，拷貝階段依然是阻塞的。
如果處理的連接數(shù)不是很高的話，使用select/epoll的web server?不一定比使用mutil-threading + blocking IO的web server?性能更好，可能延遲還更大。select/epoll 的優(yōu)勢并不是對于單個連接能處理得更好，而是在于性能更多的連接，比如Redis、Netty都是采用這種IO模型。
4. 信號驅動IO模型
當用戶應用線程調用linux操作系統(tǒng)的sigaction函數(shù)，直接返回，然后該線程去做其他事情了，當有數(shù)據(jù)來了的時候，內核空間會去遞交信號給用戶空間，此時用戶空間會調用recvfrom函數(shù)去將數(shù)據(jù)從內核空間緩沖區(qū)拷貝到用戶空間緩沖區(qū)，并處理數(shù)據(jù)。
打比方理解：
你給女神發(fā)短信，她下樓了主動通知你，你這時候在宿舍門口等著把她待會自己宿舍。同比，進程無需等待內核數(shù)據(jù)準備結果，直接返回，事件信號通知進程結果，進程把數(shù)據(jù)copy到用戶空間。
優(yōu)點：
- 從一定意義上實現(xiàn)了異步，也就是數(shù)據(jù)的準備階段是異步非阻塞執(zhí)行的
缺點：
- 當調用的線程過多，對應的信號量會增多，SIGIO函數(shù)處理不及時，會導致保存信號的隊列溢出
- 內核空間與用戶空間頻繁的進行信號量的交互，性能很差。
現(xiàn)實中這種模式用的不多，就不展開闡述了。縱觀上述的所有IO模型：BIO、NIO、多路復用、信號驅動，本質上從內核緩沖區(qū)拷貝數(shù)據(jù)到程序緩沖區(qū)的過程都是阻塞的，如果想要做到真正意義上的異步非阻塞IO，那么就牽扯到了異步IO模型。
5. 異步IO模型AIO
異步非阻塞模型，該模型是真正意義上的異步非阻塞式IO，數(shù)據(jù)準備與復制階段都是異步非阻塞的。
在該模型中，首先用戶進程中會創(chuàng)建一個Sigio?信號處理程序，然后會系統(tǒng)調用sigaction?信號處理函數(shù)，緊接著內核會直接讓用戶進程中的線程返回，用戶進程可在這期間干別的工作，當內核中的數(shù)據(jù)準備好之后，內核會生成一個Sigio?信號，通知對應的用戶進程數(shù)據(jù)已準備就緒，然后由用戶進程在觸發(fā)一個recvfrom的系統(tǒng)調用，從內核中將數(shù)據(jù)拷貝出來進行處理。
打比方理解：
你給女神發(fā)短信，女神準備好了并且主動來到你宿舍通知你，你開門。 同比，應用進程把IO請求傳給內核后，完全由內核去操作文件拷貝到用戶空間。內核完成相關操作后，會發(fā)信號告訴應用進程本次IO已經(jīng)完成。
優(yōu)點：
- 真正實現(xiàn)了異步非阻塞，吞吐量高
缺點：
- 對內核有要求，比如Linux系統(tǒng)中，異步IO在2.6才引入
總結
本文講解了Linux系統(tǒng)中5中IO模型，其中前面4種都屬于同步IO，因為數(shù)據(jù)拷貝階段都是處于阻塞狀態(tài)，只有異步IO模型才真正實現(xiàn)了異步非阻塞。
?
