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