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