轉(zhuǎn)載：http://www.lxweimin.com/p/38b56531565d

一、NIO Reactor線程模型

1、Reactor模式思想：分而治之+事件驅(qū)動

1) 分而治之

一個連接里完整的網(wǎng)絡(luò)處理過程一般分為accept、read、decode、process、encode、send這幾步。

Reactor模式將每個步驟映射為一個Task，服務(wù)端線程執(zhí)行的最小邏輯單元不再是一次完整的網(wǎng)絡(luò)請求，而是Task，且采用非阻塞方式執(zhí)行。

2) 事件驅(qū)動

每個Task對應(yīng)特定網(wǎng)絡(luò)事件。當(dāng)Task準(zhǔn)備就緒時，Reactor收到對應(yīng)的網(wǎng)絡(luò)事件通知，并將Task分發(fā)給綁定了對應(yīng)網(wǎng)絡(luò)事件的Handler執(zhí)行。

3) 幾個角色

Reactor：負(fù)責(zé)響應(yīng)事件，將事件分發(fā)給綁定了該事件的Handler處理；

Handler：事件處理器，綁定了某類事件，負(fù)責(zé)執(zhí)行對應(yīng)事件的Task對事件進(jìn)行處理；

Acceptor：Handler的一種，綁定了connect事件。當(dāng)客戶端發(fā)起connect請求時，Reactor會將accept事件分發(fā)給Acceptor處理。

2、單線程Reactor

1）優(yōu)點(diǎn)：

不需要做并發(fā)控制，代碼實(shí)現(xiàn)簡單清晰。

2）缺點(diǎn)：

a)不能利用多核CPU；

b)一個線程需要執(zhí)行處理所有的accept、read、decode、process、encode、send事件，處理成百上千的鏈路時性能上無法支撐；

c)一旦reactor線程意外跑飛或者進(jìn)入死循環(huán)，會導(dǎo)致整個系統(tǒng)通信模塊不可用。

3、多線程Reactor

特點(diǎn)：

a)有專門一個reactor線程用于監(jiān)聽服務(wù)端ServerSocketChannel，接收客戶端的TCP連接請求；

b)網(wǎng)絡(luò)IO的讀/寫操作等由一個worker reactor線程池負(fù)責(zé)，由線程池中的NIO線程負(fù)責(zé)監(jiān)聽SocketChannel事件，進(jìn)行消息的讀取、解碼、編碼和發(fā)送。

c)一個NIO線程可以同時處理N條鏈路，但是一個鏈路只注冊在一個NIO線程上處理，防止發(fā)生并發(fā)操作問題。

4、主從多線程

在絕大多數(shù)場景下，Reactor多線程模型都可以滿足性能需求；但是在極個別特殊場景中，一個NIO線程負(fù)責(zé)監(jiān)聽和處理所有的客戶端連接可能會存在性能問題。

特點(diǎn)：

a)服務(wù)端用于接收客戶端連接的不再是個1個單獨(dú)的reactor線程，而是一個boss reactor線程池；

b)服務(wù)端啟用多個ServerSocketChannel監(jiān)聽不同端口時，每個ServerSocketChannel的監(jiān)聽工作可以由線程池中的一個NIO線程完成。

二、Netty線程模型

netty線程模型采用“服務(wù)端監(jiān)聽線程”和“IO線程”分離的方式，與多線程Reactor模型類似。

抽象出NioEventLoop來表示一個不斷循環(huán)執(zhí)行處理任務(wù)的線程，每個NioEventLoop有一個selector，用于監(jiān)聽綁定在其上的socket鏈路。

1、串行化設(shè)計避免線程競爭

netty采用串行化設(shè)計理念，從消息的讀取->解碼->處理->編碼->發(fā)送，始終由IO線程N(yùn)ioEventLoop負(fù)責(zé)。整個流程不會進(jìn)行線程上下文切換，數(shù)據(jù)無并發(fā)修改風(fēng)險。

一個NioEventLoop聚合一個多路復(fù)用器selector，因此可以處理多個客戶端連接。

netty只負(fù)責(zé)提供和管理“IO線程”，其他的業(yè)務(wù)線程模型由用戶自己集成。

時間可控的簡單業(yè)務(wù)建議直接在“IO線程”上處理，復(fù)雜和時間不可控的業(yè)務(wù)建議投遞到后端業(yè)務(wù)線程池中處理。

2、定時任務(wù)與時間輪

NioEventLoop中的Thread線程按照時間輪中的步驟不斷循環(huán)執(zhí)行：

a)在時間片Tirck內(nèi)執(zhí)行selector.select()輪詢監(jiān)聽IO事件；

b)處理監(jiān)聽到的就緒IO事件；

c)執(zhí)行任務(wù)隊列taskQueue/delayTaskQueue中的非IO任務(wù)。

三、NioEventLoop與NioChannel類關(guān)系

一個NioEventLoopGroup下包含多個NioEventLoop

每個NioEventLoop中包含有一個Selector，一個taskQueue，一個delayedTaskQueue

每個NioEventLoop的Selector上可以注冊監(jiān)聽多個AbstractNioChannel.ch

每個AbstractNioChannel只會綁定在唯一的NioEventLoop上

每個AbstractNioChannel都綁定有一個自己的DefaultChannelPipeline

四、NioEventLoop線程執(zhí)行過程

1、輪詢監(jiān)聽的IO事件

1）netty的輪詢注冊機(jī)制

netty將AbstractNioChannel內(nèi)部的jdk類SelectableChannel對象注冊到NioEventLoopGroup中的jdk類Selector對象上去，并且將AbstractNioChannel作為SelectableChannel對象的一個attachment附屬上。

這樣在Selector輪詢到某個SelectableChannel有IO事件發(fā)生時，就可以直接取出IO事件對應(yīng)的AbstractNioChannel進(jìn)行后續(xù)操作。

2）循環(huán)執(zhí)行阻塞selector.select(timeoutMIllis)操作直到以下條件產(chǎn)生

a)輪詢到了IO事件（selectedKey != 0）

b)oldWakenUp參數(shù)為true

c)任務(wù)隊列里面有待處理任務(wù)（hasTasks()）

d)第一個定時任務(wù)即將要被執(zhí)行（hasScheduledTasks()）

e)用戶主動喚醒（wakenUp.get()==true）

3）解決JDK的NIO epoll bug

該bug會導(dǎo)致Selector一直空輪詢，最終導(dǎo)致cpu 100%。

在每次selector.select(timeoutMillis)后，如果沒有監(jiān)聽到就緒IO事件，會記錄此次select的耗時。如果耗時不足timeoutMillis，說明select操作沒有阻塞那么長時間，可能觸發(fā)了空輪詢，進(jìn)行一次計數(shù)。

計數(shù)累積超過閾值（默認(rèn)512）后，開始進(jìn)行Selector重建：

a)拿到有效的selectionKey集合

b)取消該selectionKey在舊的selector上的事件注冊

c)將該selectionKey對應(yīng)的Channel注冊到新的selector上，生成新的selectionKey

d)重新綁定Channel和新的selectionKey的關(guān)系

4）netty優(yōu)化了sun.nio.ch.SelectorImpl類中的selectedKeys和publicSelectedKeys這兩個field的實(shí)現(xiàn)

netty通過反射將這兩個filed替換掉，替換后的field采用數(shù)組實(shí)現(xiàn)。

這樣每次在輪詢到nio事件的時候，netty只需要O(1)的時間復(fù)雜度就能將SelectionKey塞到set中去，而jdk原有field底層使用的hashSet需要O(lgn)的時間復(fù)雜度。

2、處理IO事件

1）對于boss NioEventLoop來說，輪詢到的是基本上是連接事件（OP_ACCEPT）：

a)socketChannel = ch.accept()；

b)將socketChannel綁定到worker NioEventLoop上；

c)socketChannel在worker NioEventLoop上創(chuàng)建register0任務(wù)；

d)pipeline.fireChannelReadComplete();

2）對于worker NioEventLoop來說，輪詢到的基本上是IO讀寫事件（以O(shè)P_READ為例）：

a)ByteBuffer.allocateDirect(capacity)；

b)socketChannel.read(dst);

c)pipeline.fireChannelRead();

d)pipeline.fireChannelReadComplete();

3、處理任務(wù)隊列

1）處理用戶產(chǎn)生的普通任務(wù)

NioEventLoop中的Queue taskQueue被用來承載用戶產(chǎn)生的普通Task。

taskQueue被實(shí)現(xiàn)為netty的mpscQueue，即多生產(chǎn)者單消費(fèi)者隊列。netty使用該隊列將外部用戶線程產(chǎn)生的Task聚集，并在reactor線程內(nèi)部用單線程的方式串行執(zhí)行隊列中的Task。

當(dāng)用戶在非IO線程調(diào)用Channel的各種方法執(zhí)行Channel相關(guān)的操作時，比如channel.write()、channel.flush()等，netty會將相關(guān)操作封裝成一個Task并放入taskQueue中，保證相關(guān)操作在IO線程中串行執(zhí)行。

2）處理用戶產(chǎn)生的定時任務(wù)

NioEventLoop中的Queue> delayedTaskQueue = new PriorityQueue被用來承載用戶產(chǎn)生的定時Task。

當(dāng)用戶在非IO線程需要產(chǎn)生定時操作時，netty將用戶的定時操作封裝成ScheduledFutureTask，即一個netty內(nèi)部的定時Task，并將定時Task放入delayedTaskQueue中等待對應(yīng)Channel的IO線程串行執(zhí)行。

為了解決多線程并發(fā)寫入delayedTaskQueue的問題，netty將添加ScheduledFutureTask到delayedTaskQueue中的操作封裝成普通Task，放入taskQueue中，通過NioEventLoop的IO線程對delayedTaskQueue進(jìn)行單線程寫操作。

3）處理任務(wù)隊列的邏輯

a)將已到期的定時Task從delayedTaskQueue中轉(zhuǎn)移到taskQueue中

b)計算本次循環(huán)執(zhí)行的截止時間

c)循環(huán)執(zhí)行taskQueue中的任務(wù)，每隔64個任務(wù)檢查一下是否已過截止時間，直到taskQueue中任務(wù)全部執(zhí)行完或者超過執(zhí)行截止時間。

五、Netty中Reactor線程和worker線程所處理的事件

1、Server端NioEventLoop處理的事件

2、Client端NioEventLoop處理的事件