[[336614]]

I/O技術(shù)在系統(tǒng)設(shè)計(jì)、性能優(yōu)化、中間件研發(fā)中的使用越來越重要，學(xué)習(xí)和掌握I/O相關(guān)技術(shù)已經(jīng)不僅是一個(gè)Java攻城獅的加分技能，而是一個(gè)必備技能。本文將帶你了解BIO/NIO/AIO的發(fā)展歷程及實(shí)現(xiàn)原理，并介紹當(dāng)前流行框架Netty的基本原理。

文末福利：孤盡獨(dú)家解讀《Java開發(fā)手冊(cè)(嵩山版)》。

一 Java I/O模型

1 BIO(Blocking IO)

BIO是同步阻塞模型，一個(gè)客戶端連接對(duì)應(yīng)一個(gè)處理線程。在BIO中，accept和read方法都是阻塞操作，如果沒有連接請(qǐng)求，accept方法阻塞;如果無數(shù)據(jù)可讀取，read方法阻塞。

2 NIO(Non Blocking IO)

NIO是同步非阻塞模型，服務(wù)端的一個(gè)線程可以處理多個(gè)請(qǐng)求，客戶端發(fā)送的連接請(qǐng)求注冊(cè)在多路復(fù)用器Selector上，服務(wù)端線程通過輪詢多路復(fù)用器查看是否有IO請(qǐng)求，有則進(jìn)行處理。

NIO的三大核心組件：

Buffer：用于存儲(chǔ)數(shù)據(jù)，底層基于數(shù)組實(shí)現(xiàn)，針對(duì)8種基本類型提供了對(duì)應(yīng)的緩沖區(qū)類。

Channel：用于進(jìn)行數(shù)據(jù)傳輸，面向緩沖區(qū)進(jìn)行操作，支持雙向傳輸，數(shù)據(jù)可以從Channel讀取到Buffer中，也可以從Buffer寫到Channel中。

Selector：選擇器，當(dāng)向一個(gè)Selector中注冊(cè)Channel后，Selector 內(nèi)部的機(jī)制就可以自動(dòng)不斷地查詢(Select)這些注冊(cè)的Channel是否有已就緒的 I/O 事件(例如可讀，可寫，網(wǎng)絡(luò)連接完成等)，這樣程序就可以很簡(jiǎn)單地使用一個(gè)線程高效地管理多個(gè)Channel，也可以說管理多個(gè)網(wǎng)絡(luò)連接，因此，Selector也被稱為多路復(fù)用器。當(dāng)某個(gè)Channel上面發(fā)生了讀或者寫事件，這個(gè)Channel就處于就緒狀態(tài)，會(huì)被Selector監(jiān)聽到，然后通過SelectionKeys可以獲取就緒Channel的集合，進(jìn)行后續(xù)的I/O操作。

Epoll是Linux下多路復(fù)用IO接口select/poll的增強(qiáng)版本，它能顯著提高程序在大量并發(fā)連接中只有少量活躍的情況下的系統(tǒng)CPU利用率，獲取事件的時(shí)候，它無須遍歷整個(gè)被偵聽的描述符集，只要遍歷那些被內(nèi)核IO事件異步喚醒而加入Ready隊(duì)列的描述符集合就行了。

3 AIO(NIO 2.0)

AIO是異步非阻塞模型，一般用于連接數(shù)較多且連接時(shí)間較長(zhǎng)的應(yīng)用，在讀寫事件完成后由回調(diào)服務(wù)去通知程序啟動(dòng)線程進(jìn)行處理。與NIO不同，當(dāng)進(jìn)行讀寫操作時(shí)，只需直接調(diào)用read或write方法即可。這兩種方法均為異步的，對(duì)于讀操作而言，當(dāng)有流可讀取時(shí)，操作系統(tǒng)會(huì)將可讀的流傳入read方法的緩沖區(qū)，并通知應(yīng)用程序;對(duì)于寫操作而言，當(dāng)操作系統(tǒng)將write方法傳遞的流寫入完畢時(shí)，操作系統(tǒng)主動(dòng)通知應(yīng)用程序。可以理解為，read/write方法都是異步的，完成后會(huì)主動(dòng)調(diào)用回調(diào)函數(shù)。

二 I/O模型演化

1 傳統(tǒng)I/O模型

對(duì)于傳統(tǒng)的I/O通信方式來說，客戶端連接到服務(wù)端，服務(wù)端接收客戶端請(qǐng)求并響應(yīng)的流程為：讀取 -> 解碼 -> 應(yīng)用處理 -> 編碼 -> 發(fā)送結(jié)果。服務(wù)端為每一個(gè)客戶端連接新建一個(gè)線程，建立通道，從而處理后續(xù)的請(qǐng)求，也就是BIO的方式。

這種方式在客戶端數(shù)量不斷增加的情況下，對(duì)于連接和請(qǐng)求的響應(yīng)會(huì)急劇下降，并且占用太多線程浪費(fèi)資源，線程數(shù)量也不是沒有上限的，會(huì)遇到各種瓶頸。雖然可以使用線程池進(jìn)行優(yōu)化，但是依然有諸多問題，比如在線程池中所有線程都在處理請(qǐng)求時(shí)，無法響應(yīng)其他的客戶端連接，每個(gè)客戶端依舊需要專門的服務(wù)端線程來服務(wù)，即使此時(shí)客戶端無請(qǐng)求，也處于阻塞狀態(tài)無法釋放。基于此，提出了基于事件驅(qū)動(dòng)的Reactor模型。

2 Reactor模型

Reactor模式是基于事件驅(qū)動(dòng)開發(fā)的，服務(wù)端程序處理傳入多路請(qǐng)求，并將它們同步分派給請(qǐng)求對(duì)應(yīng)的處理線程，Reactor模式也叫Dispatcher模式，即I/O多路復(fù)用統(tǒng)一監(jiān)聽事件，收到事件后分發(fā)(Dispatch給某進(jìn)程)，這是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一。

Reactor模式以NIO為底層支持，核心組成部分包括Reactor和Handler：

• Reactor：Reactor在一個(gè)單獨(dú)的線程中運(yùn)行，負(fù)責(zé)監(jiān)聽和分發(fā)事件，分發(fā)給適當(dāng)?shù)奶幚沓绦騺韺?duì)I/O事件做出反應(yīng)。它就像公司的電話接線員，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人。
• Handlers：處理程序執(zhí)行I/O事件要完成的實(shí)際事件，Reactor通過調(diào)度適當(dāng)?shù)奶幚沓绦騺眄憫?yīng) I/O 事件，處理程序執(zhí)行非阻塞操作。類似于客戶想要與之交談的公司中的實(shí)際員工。

根據(jù)Reactor的數(shù)量和Handler線程數(shù)量，可以將Reactor分為三種模型:

• 單線程模型 (單Reactor單線程)
• 多線程模型 (單Reactor多線程)
• 主從多線程模型 (多Reactor多線程)

單線程模型

Reactor內(nèi)部通過Selector監(jiān)控連接事件，收到事件后通過dispatch進(jìn)行分發(fā)，如果是連接建立的事件，則由Acceptor處理，Acceptor通過accept接受連接，并創(chuàng)建一個(gè)Handler來處理連接后續(xù)的各種事件，如果是讀寫事件，直接調(diào)用連接對(duì)應(yīng)的Handler來處理。

Handler完成read -> (decode -> compute -> encode) ->send的業(yè)務(wù)流程。

這種模型好處是簡(jiǎn)單，壞處卻很明顯，當(dāng)某個(gè)Handler阻塞時(shí)，會(huì)導(dǎo)致其他客戶端的handler和accpetor都得不到執(zhí)行，無法做到高性能，只適用于業(yè)務(wù)處理非?？焖俚膱?chǎng)景，如redis讀寫操作。

多線程模型

主線程中，Reactor對(duì)象通過Selector監(jiān)控連接事件,收到事件后通過dispatch進(jìn)行分發(fā)，如果是連接建立事件，則由Acceptor處理，Acceptor通過accept接收連接，并創(chuàng)建一個(gè)Handler來處理后續(xù)事件，而Handler只負(fù)責(zé)響應(yīng)事件，不進(jìn)行業(yè)務(wù)操作，也就是只進(jìn)行read讀取數(shù)據(jù)和write寫出數(shù)據(jù)，業(yè)務(wù)處理交給一個(gè)線程池進(jìn)行處理。

線程池分配一個(gè)線程完成真正的業(yè)務(wù)處理，然后將響應(yīng)結(jié)果交給主進(jìn)程的Handler處理，Handler將結(jié)果send給client。

單Reactor承擔(dān)所有事件的監(jiān)聽和響應(yīng)，而當(dāng)我們的服務(wù)端遇到大量的客戶端同時(shí)進(jìn)行連接，或者在請(qǐng)求連接時(shí)執(zhí)行一些耗時(shí)操作，比如身份認(rèn)證，權(quán)限檢查等，這種瞬時(shí)的高并發(fā)就容易成為性能瓶頸。

主從多線程模型

存在多個(gè)Reactor，每個(gè)Reactor都有自己的Selector選擇器，線程和dispatch。

主線程中的mainReactor通過自己的Selector監(jiān)控連接建立事件，收到事件后通過Accpetor接收，將新的連接分配給某個(gè)子線程。

子線程中的subReactor將mainReactor分配的連接加入連接隊(duì)列中通過自己的Selector進(jìn)行監(jiān)聽，并創(chuàng)建一個(gè)Handler用于處理后續(xù)事件。

Handler完成read -> 業(yè)務(wù)處理 -> send的完整業(yè)務(wù)流程。

關(guān)于Reactor，最權(quán)威的資料應(yīng)該是Doug Lea大神的Scalable IO in Java，有興趣的同學(xué)可以看看。

三 Netty線程模型

Netty線程模型就是Reactor模式的一個(gè)實(shí)現(xiàn)，如下圖所示：

1 線程組

Netty抽象了兩組線程池BossGroup和WorkerGroup，其類型都是NioEventLoopGroup，BossGroup用來接受客戶端發(fā)來的連接，WorkerGroup則負(fù)責(zé)對(duì)完成TCP三次握手的連接進(jìn)行處理。

NioEventLoopGroup里面包含了多個(gè)NioEventLoop，管理NioEventLoop的生命周期。每個(gè)NioEventLoop中包含了一個(gè)NIO Selector、一個(gè)隊(duì)列、一個(gè)線程;其中線程用來做輪詢注冊(cè)到Selector上的Channel的讀寫事件和對(duì)投遞到隊(duì)列里面的事件進(jìn)行處理。

Boss NioEventLoop線程的執(zhí)行步驟：

• 處理accept事件, 與client建立連接, 生成NioSocketChannel。
• 將NioSocketChannel注冊(cè)到某個(gè)worker NIOEventLoop上的selector。
• 處理任務(wù)隊(duì)列的任務(wù)， 即runAllTasks。

Worker NioEventLoop線程的執(zhí)行步驟：

• 輪詢注冊(cè)到自己Selector上的所有NioSocketChannel的read和write事件。
• 處理read和write事件，在對(duì)應(yīng)NioSocketChannel處理業(yè)務(wù)。
• runAllTasks處理任務(wù)隊(duì)列TaskQueue的任務(wù)，一些耗時(shí)的業(yè)務(wù)處理可以放入TaskQueue中慢慢處理，這樣不影響數(shù)據(jù)在pipeline中的流動(dòng)處理。

Worker NIOEventLoop處理NioSocketChannel業(yè)務(wù)時(shí)，使用了pipeline (管道)，管道中維護(hù)了handler處理器鏈表，用來處理channel中的數(shù)據(jù)。

2 ChannelPipeline

Netty將Channel的數(shù)據(jù)管道抽象為ChannelPipeline，消息在ChannelPipline中流動(dòng)和傳遞。ChannelPipeline持有I/O事件攔截器ChannelHandler的雙向鏈表，由ChannelHandler對(duì)I/O事件進(jìn)行攔截和處理，可以方便的新增和刪除ChannelHandler來實(shí)現(xiàn)不同的業(yè)務(wù)邏輯定制，不需要對(duì)已有的ChannelHandler進(jìn)行修改，能夠?qū)崿F(xiàn)對(duì)修改封閉和對(duì)擴(kuò)展的支持。

ChannelPipeline是一系列的ChannelHandler實(shí)例，流經(jīng)一個(gè)Channel的入站和出站事件可以被ChannelPipeline 攔截。每當(dāng)一個(gè)新的Channel被創(chuàng)建了，都會(huì)建立一個(gè)新的ChannelPipeline并綁定到該Channel上，這個(gè)關(guān)聯(lián)是永久性的;Channel既不能附上另一個(gè)ChannelPipeline也不能分離當(dāng)前這個(gè)。這些都由Netty負(fù)責(zé)完成，而無需開發(fā)人員的特別處理。

根據(jù)起源,一個(gè)事件將由ChannelInboundHandler或ChannelOutboundHandler處理，ChannelHandlerContext實(shí)現(xiàn)轉(zhuǎn)發(fā)或傳播到下一個(gè)ChannelHandler。一個(gè)ChannelHandler處理程序可以通知ChannelPipeline中的下一個(gè)ChannelHandler執(zhí)行。Read事件(入站事件)和write事件(出站事件)使用相同的pipeline，入站事件會(huì)從鏈表head 往后傳遞到最后一個(gè)入站的handler，出站事件會(huì)從鏈表tail往前傳遞到最前一個(gè)出站的 handler，兩種類型的 handler 互不干擾。

ChannelInboundHandler回調(diào)方法：

ChannelOutboundHandler回調(diào)方法：

3 異步非阻塞

寫操作：通過NioSocketChannel的write方法向連接里面寫入數(shù)據(jù)時(shí)候是非阻塞的，馬上會(huì)返回，即使調(diào)用寫入的線程是我們的業(yè)務(wù)線程。Netty通過在ChannelPipeline中判斷調(diào)用NioSocketChannel的write的調(diào)用線程是不是其對(duì)應(yīng)的NioEventLoop中的線程，如果發(fā)現(xiàn)不是則會(huì)把寫入請(qǐng)求封裝為WriteTask投遞到其對(duì)應(yīng)的NioEventLoop中的隊(duì)列里面，然后等其對(duì)應(yīng)的NioEventLoop中的線程輪詢讀寫事件時(shí)候，將其從隊(duì)列里面取出來執(zhí)行。

讀操作：當(dāng)從NioSocketChannel中讀取數(shù)據(jù)時(shí)候，并不是需要業(yè)務(wù)線程阻塞等待，而是等NioEventLoop中的IO輪詢線程發(fā)現(xiàn)Selector上有數(shù)據(jù)就緒時(shí)，通過事件通知方式來通知業(yè)務(wù)數(shù)據(jù)已就緒，可以來讀取并處理了。

每個(gè)NioSocketChannel對(duì)應(yīng)的讀寫事件都是在其對(duì)應(yīng)的NioEventLoop管理的單線程內(nèi)執(zhí)行，對(duì)同一個(gè)NioSocketChannel不存在并發(fā)讀寫，所以無需加鎖處理。

使用Netty框架進(jìn)行網(wǎng)絡(luò)通信時(shí)，當(dāng)我們發(fā)起I/O請(qǐng)求后會(huì)馬上返回，而不會(huì)阻塞我們的業(yè)務(wù)調(diào)用線程;如果想要獲取請(qǐng)求的響應(yīng)結(jié)果，也不需要業(yè)務(wù)調(diào)用線程使用阻塞的方式來等待，而是當(dāng)響應(yīng)結(jié)果出來的時(shí)候，使用I/O線程異步通知業(yè)務(wù)的方式，所以在整個(gè)請(qǐng)求 -> 響應(yīng)過程中業(yè)務(wù)線程不會(huì)由于阻塞等待而不能干其他事情。