1 前言
我們都知道，為了實現高性能的通信服務器，BIO在高并發(fā)的情況下會出現性能急劇下降的問題，甚至會由于創(chuàng)建過多線程而導致系統(tǒng)OOM。因此在Java業(yè)界，BIO的性能問題一直被開發(fā)者所詬病，所幸的是，JDK1.4推出了NIO，NIO基本解決了BIO的性能問題，是目前實現Java高性能服務器的基礎框架。NIO官方的叫法叫做New IO,而對應于操作系統(tǒng)層面來說其實也是Non-Blocking IO。
大名鼎鼎的Netty就是NIO框架，而目前很多開源框架比如Dubbo，RocketMQ,Seata，Spark，Flink都是采用Netty作為基礎通信組件。因此，學好Netty很重要，但是NIO作為Netty的基礎，這里想說的是學好NIO也一樣重要！
學好NIO，那么必須先理解操作系統(tǒng)層面的5種網絡IO模型。
2 5種IO模型
2.1 阻塞IO模型
阻塞IO模型如下圖：
從上圖可以看到，不管有無數據報到來，進程（線程）是阻塞于recvfrom系統(tǒng)調用的。這是什么意思呢？說白了就是假如我們要用套接字讀取數據，此時我們必然會調用read方法，此時這個read方法就會觸發(fā)操作系統(tǒng)內核的一次recvfrom系統(tǒng)調用，此時有兩種情況：
-
內核還未接收到遠端數據，此時數據報沒有準備好，那么讀取數據的線程就會一直阻塞，直到遠端發(fā)來數據報，這一阻塞的過程對應上圖序號1的過程；然后在數據報被從內核復制到用戶空間這一過程中，該線程會再次阻塞，直到復制完成，這一過程對應上圖的序號2的過程； -
內核已經接收到遠端數據，此時數據報已經準備好，那么數據報就會被從內核復制到用戶空間，這一過程是阻塞的，對應上圖序號2的過程。
可見，阻塞IO模型的話，讀一次數據會發(fā)生一次recvfrom系統(tǒng)調用,整個過程都是阻塞的，即在內核的數據報還未準備好的時候，此時用戶進程（ 線程）阻塞；當內核的數據報準備好的時候，此時數據報要從內核拷貝到用戶空間，此時用戶進程（線程）也一直阻塞；直到數據報拷貝到用戶空間后，此時用戶進程（線程）才會醒過來，然后處理這些數據報即執(zhí)行一些用戶的業(yè)務邏輯。當然，如果用戶進程（線程）在阻塞過程中，如果recvfrom系統(tǒng)調用被信號中斷，此時阻塞也是會被喚醒的。
思考： 這里的recvfrom系統(tǒng)調用被信號中斷什么情況下會發(fā)生？這個信號中斷指的是線程中斷（Thread.interrupt()）么？自行思考。
2.2 非阻塞IO模型
2.2 非阻塞IO模型
非阻塞IO模型如下圖：
如上圖，根據內核中的數據報有無準備好，有以下兩種情形：
-
當內核中的數據報還沒準備好，此時recvfrom系統(tǒng)調用立即返回一個EWOULDBLOCK錯誤，即不會將用戶進程（線程）至于阻塞狀態(tài)。我們拿Java的NIO來說，當我們配置ServerSocketChannel.configureBlocking(false);或SocketChannel..configureBlocking(false);時，我們調用ServerSocketChannel.accept()的null或SocketChannel.read(buffer)不會阻塞的，若沒有新連接接入或內核中沒有數據報準備好，此時會理解返回null或 0的返回結果,說白了這個返回結果就是對應EWOULDBLOCK錯誤； -
當內核中的數據報已經準備好時，此時recvfrom系統(tǒng)調用，用戶進程（線程）還是會阻塞，直到內核中的數據報已經拷貝到了用戶空間，此時用戶進程（線程）才會被喚醒來處理接收的數據報。
非阻塞IO在用戶數據報還沒準備好的時候，recvfrom系統(tǒng)調用不會阻塞，接著會繼續(xù)進行下一輪的recvfrom系統(tǒng)調用看數據報有無準備好，周而復始，進程（線程）不斷輪訓，因此這是非常耗費CPU的。這種模型不是很常用，適合用在某臺CPU專為某些功能準備的場合。
2.3 IO復用模型
2.3 IO復用模型
IO復用模型如下圖：
初步從以上IO復用模型來看，這不是跟IO阻塞模型差不多么？當內核無數據報準備好時，select系統(tǒng)調用會阻塞；當內核數據拷貝到用戶空間時，此時recvfrom系統(tǒng)調用依然會阻塞，實在是看不到跟IO阻塞模型有啥區(qū)別？區(qū)別就是IO復用模型還比阻塞IO模型還多一次recvfrom系統(tǒng)調用，這不是明擺著多浪費一次CPU資源么？
如果我們這么想，那為什么IO復用模型得到大規(guī)模廣泛應用呢？其實IO復用模型真正占優(yōu)勢的地方在于select操作，這個select操作可以選擇多個文件描述符，分別對應Java NIO中的OP_CONNECT,OP_ACCEPT,OP_READ和OP_WRITE就緒事件。正是基于一次recvfrom系統(tǒng)調用中一個線程的select操作可以選擇多個文件描述符這個功能，我們現在用一個用戶線程就能監(jiān)聽不同channel的OP_CONNECT,OP_ACCEPT,OP_READ和OP_WRITE這些就緒事件，然后根據某個就緒事件拿到相應的channel來做對應的操作。而不用像阻塞IO模型或非阻塞IO模型那樣，一次recvfrom系統(tǒng)調用中一個線程就只能選擇一個文件描述符，這樣就嚴重限制了伸縮性。這么說很抽象，就比如拿阻塞IO模型來說，由于用戶進程（線程）每一次recvfrom系統(tǒng)調用都是阻塞且只對應一個文件描述符，此時如果服務端線程阻塞于客戶端A的讀操作時，如果有另外的客戶端B需要接入服務端，此時服務端線程由于阻塞于客戶端A的讀操作，因此無法處理客戶端B的連接操作。此時，必然要一個線程一個文件描述符即服務端線程每accept了一個客戶端連接，此時就需要新建一個線程去處理這個客戶端連接的讀寫操作。我們都知道，線程是一種很昂貴的CPU資源，當開啟成千上萬的線程后，線程切換的成本很高，CPU性能肯定下降，說不定高并發(fā)下還會OOM。說到這里，也許有同學會說，對于阻塞IO模型，我們不一個線程一個socket，用線程池替代，當然，這是一個優(yōu)化的點，但沒解決阻塞IO模型的根本。怎么說呢？當線程池的所有線程都阻塞于客戶端的讀或寫操作時，此時其他新接入的線程將會積壓在線程池的隊列中阻塞等待。
2.4 信號驅動IO模型
2.4 信號驅動IO模型
信號驅動IO模型如下圖：
可見，信號驅動IO模型在等待數據報期間是不會阻塞的，即用戶進程（線程）發(fā)送一個sigaction系統(tǒng)調用后，此時立刻返回，并不會阻塞，然后用戶進程（線程）繼續(xù)執(zhí)行；當數據報準備好時，此時內核就為該進程（線程）產生一個SIGIO信號，此時該進程（線程）就發(fā)生一次recvfrom系統(tǒng)調用將數據報從內核復制到用戶空間，注意，這個階段是阻塞的。
PS: 網上找了下信號驅動IO模型的java代碼，沒找到，會碼信號驅動IO模型代碼的下伙伴們可以教教我。
2.5 異步IO模型
2.5 異步IO模型
異步IO模型如下圖：
異步IO模型也很好理解，即用戶進程（線程）在等待數據報和數據報從內核拷貝到用戶空間這兩階段都是非阻塞的，即用戶進程（線程）發(fā)生一次系統(tǒng)調用后，立即返回，然后該用戶進程（線程）繼續(xù)往下執(zhí)行。當內核把接收到數據報并把數據報拷貝到了用戶空間后，此時再通知用戶進程（線程）來處理用戶空間的數據報。也就是說，這一些列IO操作都交給了內核去處理了，用戶進程無須同步阻塞，因此是異步非阻塞的。
擴展： 異步IO模型跟信號驅動IO模型的區(qū)別在于當內核準備好數據報后，對于信號驅動IO模型，此時內核會通知用戶進程說數據報準備好啦，你需要發(fā)起系統(tǒng)調用來將數據報從內核拷貝到用戶空間，此過程是同步阻塞的；而對于異步IO模型，當數據報準備好時，內核不會再通知用戶進程，而是自己默默將數據報從內核拷貝到用戶空間后然后再通知用戶進程說，數據已經拷貝到用戶空間啦，你直接進行業(yè)務邏輯處理就行。
3 各種IO模型區(qū)別
3 各種IO模型區(qū)別
通過5種IO模型的比對，可以發(fā)現，前4種IO模型都是同步阻塞IO模型，因為其第二階段數據報從內核拷貝到用戶空間都是同步阻塞的，只是第一階段等待數據報的處理不同；最后一種IO模型（異步IO模型）才是真正的異步非阻塞IO模型，內核將一切事情都干完（內核：我真的好累）。
4 總結
4 總結
好了，五種IO模型基本就已經總結完了，基本是自己基于《UNIX網絡編程_卷1_套接字》的讀書總結，接下來再通過java代碼將這幾種IO模型實現一遍。
參考：《UNIX網絡編程_卷1_套接字》
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
