• 1. Netty是什么
• 2. Netty線程模型
• 2.1 Reactor模式
• 2.2 Reator模式的實現(xiàn)
• 2.3 Netty模型
• 3.EventLoopGroup / EventLoop
• 4.ChannelPipeline
• 5.Buffer
• 1.ByteBuf讀寫指針
• 2.零拷貝
• 3.引用計數(shù)與池化技術
• 6、總結

1. Netty是什么

Netty是一個高性能、異步事件驅動的NIO框架，基于JAVA NIO提供的API實現(xiàn)。它提供了對TCP、UDP和文件傳輸?shù)闹С?/p>

作為一個異步NIO框架，Netty的所有IO操作都是異步非阻塞的，通過Future-Listener機制，用戶可以方便的主動獲取或者通過通知機制獲得IO操作結果。

作為當前最流行的NIO框架，Netty在互聯(lián)網(wǎng)領域、大數(shù)據(jù)分布式計算領域、游戲行業(yè)、通信行業(yè)等獲得了廣泛的應用，一些業(yè)界著名的開源組件也基于Netty的NIO框架構建。

2. Netty線程模型

在JAVA NIO方面Selector給Reactor模式提供了基礎，Netty結合Selector和Reactor模式設計了高效的線程模型。先來看下Reactor模式：

2.1 Reactor模式

Wikipedia這么解釋Reactor模型：

“The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers.”。

首先Reactor模式首先是事件驅動 的，有一個或者多個并發(fā)輸入源，有一個Server Handler和多個Request Handlers

這個Service Handler會同步的將輸入的請求多路復用的分發(fā)給相應的Request Handler。

可以如下圖所示：

從結構上有點類似生產(chǎn)者和消費者模型，即一個或多個生產(chǎn)者將事件放入一個Queue中，而一個或者多個消費者主動的從這個隊列中poll事件來處理；

而Reactor模式則沒有Queue來做緩沖，每當一個事件輸入到Service Handler之后，該Service Handler會主動根據(jù)不同的Evnent類型將其分發(fā)給對應的Request Handler來處理。

2.2 Reator模式的實現(xiàn)

關于Java NIO 構造Reator模式，Doug lea在《Scalable IO in Java》中給了很好的闡述，這里截取PPT對Reator模式的實現(xiàn)進行說明

1.第一種實現(xiàn)模型如下：

這是最簡單的Reactor單線程模型，由于Reactor模式使用的是異步非阻塞IO，所有的IO操作都不會被阻塞，理論上一個線程可以獨立處理所有的IO操作。

這時Reactor線程是個多面手，負責多路分離套接字，Accept新連接，并分發(fā)請求到處理鏈中。

對于一些小容量應用場景，可以使用到單線程模型。但對于高負載，大并發(fā)的應用卻不合適，主要原因如下：

1. 當一個NIO線程同時處理成百上千的鏈路，性能上無法支撐，即使NIO線程的CPU負荷達到100%，也無法完全處理消息

2. 當NIO線程負載過重后，處理速度會變慢，會導致大量客戶端連接超時，超時之后往往會重發(fā)，更加重了NIO線程的負載。

3. 可靠性低，一個線程意外死循環(huán)，會導致整個通信系統(tǒng)不可用

為了解決這些問題，出現(xiàn)了Reactor多線程模型。

2.Reactor多線程模型：

相比上一種模式，該模型在處理鏈部分采用了多線程（線程池）。

在絕大多數(shù)場景下，該模型都能滿足性能需求。但是，在一些特殊的應用場景下，如服務器會對客戶端的握手消息進行安全認證。這類場景下，單獨的一個Acceptor線程可能會存在性能不足的問題。

為了解決這些問題，產(chǎn)生了第三種Reactor線程模型

3.Reactor主從模型

該模型相比第二種模型，是將Reactor分成兩部分，mainReactor負責監(jiān)聽server socket，accept新連接；并將建立的socket分派給subReactor。

subReactor負責多路分離已連接的socket，讀寫網(wǎng)絡數(shù)據(jù)，對業(yè)務處理功能，其扔給worker線程池完成。通常，subReactor個數(shù)上可與CPU個數(shù)等同。

2.3 Netty模型

2.2中說完了Reactor的三種模型，那么Netty是哪一種呢？

其實Netty的線程模型是Reactor模型的變種，那就是去掉線程池的第三種形式的變種，這也是Netty NIO的默認模式。

Netty中Reactor模式的參與者主要有下面一些組件：

1. Selector
2. EventLoopGroup/EventLoop
3. ChannelPipeline

Selector即為NIO中提供的SelectableChannel多路復用器，充當著demultiplexer的角色，這里不再贅述；下面對另外兩種功能和其在Netty之Reactor模式中扮演的角色進行介紹。

3.EventLoopGroup / EventLoop

當系統(tǒng)在運行過程中，如果頻繁的進行線程上下文切換，會帶來額外的性能損耗。

多線程并發(fā)執(zhí)行某個業(yè)務流程，業(yè)務開發(fā)者還需要時刻對線程安全保持警惕，哪些數(shù)據(jù)可能會被并發(fā)修改，如何保護？這不僅降低了開發(fā)效率，也會帶來額外的性能損耗。

為了解決上述問題，Netty采用了串行化設計理念

從消息的讀取、編碼以及后續(xù)Handler的執(zhí)行，始終都由IO線程EventLoop負責，這就意味著整個流程不會進行線程上下文的切換，數(shù)據(jù)也不會面臨被并發(fā)修改的風險。這也解釋了為什么Netty線程模型去掉了Reactor主從模型中線程池。

EventLoopGroup是一組EventLoop的抽象，EventLoopGroup提供next接口，可以從一組EventLoop里面按照一定規(guī)則獲取其中一個EventLoop來處理任務

對于EventLoopGroup這里需要了解的是在Netty中，在Netty服務器編程中我們需要BossEventLoopGroup和WorkerEventLoopGroup兩個EventLoopGroup來進行工作。

通常一個服務端口即一個ServerSocketChannel對應一個Selector和一個EventLoop線程，也就是說BossEventLoopGroup的線程數(shù)參數(shù)為1。

BossEventLoop負責接收客戶端的連接并將SocketChannel交給WorkerEventLoopGroup來進行IO處理。

EventLoop的實現(xiàn)充當Reactor模式中的分發(fā)（Dispatcher）的角色。

4.ChannelPipeline

ChannelPipeline其實是擔任著Reactor模式中的請求處理器這個角色。

ChannelPipeline的默認實現(xiàn)是DefaultChannelPipeline，DefaultChannelPipeline本身維護著一個用戶不可見的tail和head的ChannelHandler，他們分別位于鏈表隊列的頭部和尾部。tail在更上層的部分，而head在靠近網(wǎng)絡層的方向。

在Netty中關于ChannelHandler有兩個重要的接口，ChannelInBoundHandler和ChannelOutBoundHandler。

inbound可以理解為網(wǎng)絡數(shù)據(jù)從外部流向系統(tǒng)內部，而outbound可以理解為網(wǎng)絡數(shù)據(jù)從系統(tǒng)內部流向系統(tǒng)外部。

用戶實現(xiàn)的ChannelHandler可以根據(jù)需要實現(xiàn)其中一個或多個接口，將其放入Pipeline中的鏈表隊列中，ChannelPipeline會根據(jù)不同的IO事件類型來找到相應的Handler來處理

同時鏈表隊列是責任鏈模式的一種變種，自上而下或自下而上所有滿足事件關聯(lián)的Handler都會對事件進行處理。

ChannelInBoundHandler對從客戶端發(fā)往服務器的報文進行處理，一般用來執(zhí)行半包/粘包，解碼，讀取數(shù)據(jù)，業(yè)務處理等；

ChannelOutBoundHandler對從服務器發(fā)往客戶端的報文進行處理，一般用來進行編碼，發(fā)送報文到客戶端。

下圖是對ChannelPipeline執(zhí)行過程的說明：

5.Buffer

Netty提供的經(jīng)過擴展的Buffer相對NIO中的有個許多優(yōu)勢，作為數(shù)據(jù)存取非常重要的一塊，我們來看看Netty中的Buffer有什么特點。

1.ByteBuf讀寫指針

• 在ByteBuffer中，讀寫指針都是position，而在ByteBuf中，讀寫指針分別為readerIndex和writerIndex

• 直觀看上去ByteBuffer僅用了一個指針就實現(xiàn)了兩個指針的功能，節(jié)省了變量，但是當對于ByteBuffer的讀寫狀態(tài)切換的時候必須要調用flip方法，而當下一次寫之前，必須要將Buffe中的內容讀完，再調用clear方法。

• 每次讀之前調用flip，寫之前調用clear，這樣無疑給開發(fā)帶來了繁瑣的步驟，而且內容沒有讀完是不能寫的，這樣非常不靈活。

• 相比之下我們看看ByteBuf，讀的時候僅僅依賴readerIndex指針，寫的時候僅僅依賴writerIndex指針，不需每次讀寫之前調用對應的方法，而且沒有必須一次讀完的限制。

2.零拷貝

• Netty的接收和發(fā)送ByteBuffer采用DIRECT BUFFERS，使用堆外直接內存進行Socket讀寫，不需要進行字節(jié)緩沖區(qū)的二次拷貝。

• 如果使用傳統(tǒng)的堆內存（HEAP BUFFERS）進行Socket讀寫，JVM會將堆內存Buffer拷貝一份到直接內存中，然后才寫入Socket中。相比于堆外直接內存，消息在發(fā)送過程中多了一次緩沖區(qū)的內存拷貝。

• Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象，用戶可以像操作一個Buffer那樣方便的對組合Buffer進行操作，避免了傳統(tǒng)通過內存拷貝的方式將幾個小Buffer合并成一個大的Buffer。

• Netty的文件傳輸采用了transferTo方法，它可以直接將文件緩沖區(qū)的數(shù)據(jù)發(fā)送到目標Channel，避免了傳統(tǒng)通過循環(huán)write方式導致的內存拷貝問題。

3.引用計數(shù)與池化技術

• 在Netty中，每個被申請的Buffer對于Netty來說都可能是很寶貴的資源，因此為了獲得對于內存的申請與回收更多的控制權，Netty自己根據(jù)引用計數(shù)法去實現(xiàn)了內存的管理。

• Netty對于Buffer的使用都是基于直接內存（DirectBuffer）實現(xiàn)的，大大提高I/O操作的效率

• 然而DirectBuffer和HeapBuffer相比之下除了I/O操作效率高之外還有一個天生的缺點，即對于DirectBuffer的申請相比HeapBuffer效率更低

• 因此Netty結合引用計數(shù)實現(xiàn)了PolledBuffer，即池化的用法，當引用計數(shù)等于0的時候，Netty將Buffer回收致池中，在下一次申請Buffer的沒某個時刻會被復用。

6、總結

Netty其實本質上就是Reactor模式的實現(xiàn)，Selector作為多路復用器，EventLoop作為轉發(fā)器，Pipeline作為事件處理器。

但是和一般的Reactor不同的是，Netty使用串行化實現(xiàn)，并在Pipeline中使用了責任鏈模式。

Netty中的buffer相對有NIO中的buffer又做了一些優(yōu)化，大大提高了性能。