本文基于 Netty 4.1 展開介紹相關(guān)理論模型，使用場景，基本組件、整體架構(gòu)，知其然且知其所以然，希望給大家在實際開發(fā)實踐、學習開源項目方面提供參考。

Netty 是一個異步事件驅(qū)動的網(wǎng)絡(luò)應用程序框架，用于快速開發(fā)可維護的高性能協(xié)議服務(wù)器和客戶端。

JDK 原生 NIO 程序的問題

JDK 原生也有一套網(wǎng)絡(luò)應用程序 API，但是存在一系列問題，主要如下：

• NIO 的類庫和 API 繁雜，使用麻煩。你需要熟練掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
• 需要具備其他的額外技能做鋪墊。例如熟悉 Java 多線程編程，因為 NIO 編程涉及到 Reactor 模式，你必須對多線程和網(wǎng)路編程非常熟悉，才能編寫出高質(zhì)量的 NIO 程序。
• 可靠性能力補齊，開發(fā)工作量和難度都非常大。例如客戶端面臨斷連重連、網(wǎng)絡(luò)閃斷、半包讀寫、失敗緩存、網(wǎng)絡(luò)擁塞和異常碼流的處理等等。

NIO 編程的特點是功能開發(fā)相對容易，但是可靠性能力補齊工作量和難度都非常大。

• JDK NIO 的 Bug。例如臭名昭著的 Epoll Bug，它會導致 Selector 空輪詢，最終導致 CPU 100%。

官方聲稱在 JDK 1.6 版本的 update 18 修復了該問題，但是直到 JDK 1.7 版本該問題仍舊存在，只不過該 Bug 發(fā)生概率降低了一些而已，它并沒有被根本解決。

Netty 的特點

Netty 對 JDK 自帶的 NIO 的 API 進行封裝，解決上述問題，主要特點有：

• 設(shè)計優(yōu)雅，適用于各種傳輸類型的統(tǒng)一 API 阻塞和非阻塞 Socket；基于靈活且可擴展的事件模型，可以清晰地分離關(guān)注點；高度可定制的線程模型 - 單線程，一個或多個線程池；真正的無連接數(shù)據(jù)報套接字支持（自 3.1 起）。
• 使用方便，詳細記錄的 Javadoc，用戶指南和示例；沒有其他依賴項，JDK 5（Netty 3.x）或 6（Netty 4.x）就足夠了。
• 高性能，吞吐量更高，延遲更低；減少資源消耗；最小化不必要的內(nèi)存復制。
• 安全，完整的 SSL/TLS 和 StartTLS 支持。
• 社區(qū)活躍，不斷更新，社區(qū)活躍，版本迭代周期短，發(fā)現(xiàn)的 Bug 可以被及時修復，同時，更多的新功能會被加入。

Netty 常見使用場景

Netty 常見的使用場景如下：

• 互聯(lián)網(wǎng)行業(yè)。在分布式系統(tǒng)中，各個節(jié)點之間需要遠程服務(wù)調(diào)用，高性能的 RPC 框架必不可少，Netty 作為異步高性能的通信框架，往往作為基礎(chǔ)通信組件被這些 RPC 框架使用。

典型的應用有：阿里分布式服務(wù)框架 Dubbo 的 RPC 框架使用 Dubbo 協(xié)議進行節(jié)點間通信，Dubbo 協(xié)議默認使用 Netty 作為基礎(chǔ)通信組件，用于實現(xiàn)各進程節(jié)點之間的內(nèi)部通信。

• 游戲行業(yè)。無論是手游服務(wù)端還是大型的網(wǎng)絡(luò)游戲，Java 語言得到了越來越廣泛的應用。Netty 作為高性能的基礎(chǔ)通信組件，它本身提供了 TCP/UDP 和 HTTP 協(xié)議棧。

非常方便定制和開發(fā)私有協(xié)議棧，賬號登錄服務(wù)器，地圖服務(wù)器之間可以方便的通過 Netty 進行高性能的通信。

• 大數(shù)據(jù)領(lǐng)域。經(jīng)典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認采用 Netty 進行跨界點通信，它的 Netty Service 基于 Netty 框架二次封裝實現(xiàn)。

有興趣的讀者可以了解一下目前有哪些開源項目使用了 Netty：Related Projects。

Netty 高性能設(shè)計

Netty 作為異步事件驅(qū)動的網(wǎng)絡(luò)，高性能之處主要來自于其 I/O 模型和線程處理模型，前者決定如何收發(fā)數(shù)據(jù)，后者決定如何處理數(shù)據(jù)。

I/O 模型

用什么樣的通道將數(shù)據(jù)發(fā)送給對方，BIO、NIO 或者 AIO，I/O 模型在很大程度上決定了框架的性能。

阻塞 I/O

傳統(tǒng)阻塞型 I/O(BIO)可以用下圖表示：

Blocking I/O

特點如下：

• 每個請求都需要獨立的線程完成數(shù)據(jù) Read，業(yè)務(wù)處理，數(shù)據(jù) Write 的完整操作問題。
• 當并發(fā)數(shù)較大時，需要創(chuàng)建大量線程來處理連接，系統(tǒng)資源占用較大。
• 連接建立后，如果當前線程暫時沒有數(shù)據(jù)可讀，則線程就阻塞在 Read 操作上，造成線程資源浪費。

I/O 復用模型

在 I/O 復用模型中，會用到 Select，這個函數(shù)也會使進程阻塞，但是和阻塞 I/O 所不同的是這兩個函數(shù)可以同時阻塞多個 I/O 操作。

而且可以同時對多個讀操作，多個寫操作的 I/O 函數(shù)進行檢測，直到有數(shù)據(jù)可讀或可寫時，才真正調(diào)用 I/O 操作函數(shù)。

Netty 的非阻塞 I/O 的實現(xiàn)關(guān)鍵是基于 I/O 復用模型，這里用 Selector 對象表示：

Nonblocking I/O

Netty 的 IO 線程 NioEventLoop 由于聚合了多路復用器 Selector，可以同時并發(fā)處理成百上千個客戶端連接。

當線程從某客戶端 Socket 通道進行讀寫數(shù)據(jù)時，若沒有數(shù)據(jù)可用時，該線程可以進行其他任務(wù)。

線程通常將非阻塞 IO 的空閑時間用于在其他通道上執(zhí)行 IO 操作，所以單獨的線程可以管理多個輸入和輸出通道。

由于讀寫操作都是非阻塞的，這就可以充分提升 IO 線程的運行效率，避免由于頻繁 I/O 阻塞導致的線程掛起。

一個 I/O 線程可以并發(fā)處理 N 個客戶端連接和讀寫操作，這從根本上解決了傳統(tǒng)同步阻塞 I/O 一連接一線程模型，架構(gòu)的性能、彈性伸縮能力和可靠性都得到了極大的提升。

基于 Buffer

傳統(tǒng)的 I/O 是面向字節(jié)流或字符流的，以流式的方式順序地從一個 Stream 中讀取一個或多個字節(jié), 因此也就不能隨意改變讀取指針的位置。

在 NIO 中，拋棄了傳統(tǒng)的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，只能從 Channel 中讀取數(shù)據(jù)到 Buffer 中或?qū)?shù)據(jù)從 Buffer 中寫入到 Channel。

基于 Buffer 操作不像傳統(tǒng) IO 的順序操作，NIO 中可以隨意地讀取任意位置的數(shù)據(jù)。

線程模型

數(shù)據(jù)報如何讀取？讀取之后的編解碼在哪個線程進行，編解碼后的消息如何派發(fā)，線程模型的不同，對性能的影響也非常大。

事件驅(qū)動模型

通常，我們設(shè)計一個事件處理模型的程序有兩種思路：

• 輪詢方式，線程不斷輪詢訪問相關(guān)事件發(fā)生源有沒有發(fā)生事件，有發(fā)生事件就調(diào)用事件處理邏輯。
• 事件驅(qū)動方式，發(fā)生事件，主線程把事件放入事件隊列，在另外線程不斷循環(huán)消費事件列表中的事件，調(diào)用事件對應的處理邏輯處理事件。事件驅(qū)動方式也被稱為消息通知方式，其實是設(shè)計模式中觀察者模式的思路。

以 GUI 的邏輯處理為例，說明兩種邏輯的不同：

• 輪詢方式，線程不斷輪詢是否發(fā)生按鈕點擊事件，如果發(fā)生，調(diào)用處理邏輯。
• 事件驅(qū)動方式，發(fā)生點擊事件把事件放入事件隊列，在另外線程消費的事件列表中的事件，根據(jù)事件類型調(diào)用相關(guān)事件處理邏輯。

這里借用 O'Reilly 大神關(guān)于事件驅(qū)動模型解釋圖：

事件驅(qū)動模型

主要包括 4 個基本組件：

• 事件隊列（event queue）：接收事件的入口，存儲待處理事件。
• 分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元。
• 事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道。
• 事件處理器（event processor）：實現(xiàn)業(yè)務(wù)邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作。

可以看出，相對傳統(tǒng)輪詢模式，事件驅(qū)動有如下優(yōu)點：

• 可擴展性好，分布式的異步架構(gòu)，事件處理器之間高度解耦，可以方便擴展事件處理邏輯。
• 高性能，基于隊列暫存事件，能方便并行異步處理事件。

Reactor 線程模型

Reactor 是反應堆的意思，Reactor 模型是指通過一個或多個輸入同時傳遞給服務(wù)處理器的服務(wù)請求的事件驅(qū)動處理模式。

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

Reactor 模型中有 2 個關(guān)鍵組成：

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

Reactor 模型

取決于 Reactor 的數(shù)量和 Hanndler 線程數(shù)量的不同，Reactor 模型有 3 個變種：

• 單 Reactor 單線程。
• 單 Reactor 多線程。
• 主從 Reactor 多線程。

可以這樣理解，Reactor 就是一個執(zhí)行 while (true) { selector.select(); …} 循環(huán)的線程，會源源不斷的產(chǎn)生新的事件，稱作反應堆很貼切。

篇幅關(guān)系，這里不再具體展開 Reactor 特性、優(yōu)缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《理解高性能網(wǎng)絡(luò)模型》。

Netty 線程模型

Netty 主要基于主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：

• MainReactor 負責客戶端的連接請求，并將請求轉(zhuǎn)交給 SubReactor。
• SubReactor 負責相應通道的 IO 讀寫請求。
• 非 IO 請求（具體邏輯處理）的任務(wù)則會直接寫入隊列，等待 worker threads 進行處理。

這里引用 Doug Lee 大神的 Reactor 介紹：Scalable IO in Java 里面關(guān)于主從 Reactor 多線程模型的圖：

主從 Rreactor 多線程模型

特別說明的是：雖然 Netty 的線程模型基于主從 Reactor 多線程，借用了 MainReactor 和 SubReactor 的結(jié)構(gòu)。但是實際實現(xiàn)上 SubReactor 和 Worker 線程在同一個線程池中：

EventLoopGroup bossGroup = new NioEventLoopGroup(); 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 
ServerBootstrap server = new ServerBootstrap(); 
server.group(bossGroup, workerGroup) 
.channel(NioServerSocketChannel.class) 

上面代碼中的 bossGroup 和 workerGroup 是 Bootstrap 構(gòu)造方法中傳入的兩個對象，這兩個 group 均是線程池：

• bossGroup 線程池則只是在 Bind 某個端口后，獲得其中一個線程作為 MainReactor，專門處理端口的 Accept 事件，每個端口對應一個 Boss 線程。
• workerGroup 線程池會被各個 SubReactor 和 Worker 線程充分利用。

異步處理

異步的概念和同步相對。當一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實際處理這個調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者。

Netty 中的 I/O 操作是異步的，包括 Bind、Write、Connect 等操作會簡單的返回一個 ChannelFuture。

調(diào)用者并不能立刻獲得結(jié)果，而是通過 Future-Listener 機制，用戶可以方便的主動獲取或者通過通知機制獲得 IO 操作結(jié)果。

當 Future 對象剛剛創(chuàng)建時，處于非完成狀態(tài)，調(diào)用者可以通過返回的 ChannelFuture 來獲取操作執(zhí)行的狀態(tài)，注冊監(jiān)聽函數(shù)來執(zhí)行完成后的操作。

常見有如下操作：

• 通過 isDone 方法來判斷當前操作是否完成。
• 通過 isSuccess 方法來判斷已完成的當前操作是否成功。
• 通過 getCause 方法來獲取已完成的當前操作失敗的原因。
• 通過 isCancelled 方法來判斷已完成的當前操作是否被取消。
• 通過 addListener 方法來注冊監(jiān)聽器，當操作已完成(isDone 方法返回完成)，將會通知指定的監(jiān)聽器；如果 Future 對象已完成，則理解通知指定的監(jiān)聽器。

例如下面的代碼中綁定端口是異步操作，當綁定操作處理完，將會調(diào)用相應的監(jiān)聽器處理邏輯。

serverBootstrap.bind(port).addListener(future -> { 
       if (future.isSuccess()) { 
           System.out.println(new Date() + ": 端口[" + port + "]綁定成功!"); 
       } else { 
           System.err.println("端口[" + port + "]綁定失敗!"); 
       } 
   }); 

相比傳統(tǒng)阻塞 I/O，執(zhí)行 I/O 操作后線程會被阻塞住, 直到操作完成；異步處理的好處是不會造成線程阻塞，線程在 I/O 操作期間可以執(zhí)行別的程序，在高并發(fā)情形下會更穩(wěn)定和更高的吞吐量。

Netty 架構(gòu)設(shè)計

前面介紹完 Netty 相關(guān)一些理論，下面從功能特性、模塊組件、運作過程來介紹 Netty 的架構(gòu)設(shè)計。

功能特性

Netty 功能特性如下：

• 傳輸服務(wù)，支持 BIO 和 NIO。
• 容器集成，支持 OSGI、JBossMC、Spring、Guice 容器。
• 協(xié)議支持，HTTP、Protobuf、二進制、文本、WebSocket 等一系列常見協(xié)議都支持。還支持通過實行編碼解碼邏輯來實現(xiàn)自定義協(xié)議。
• Core 核心，可擴展事件模型、通用通信 API、支持零拷貝的 ByteBuf 緩沖對象。

模塊組件

Bootstrap、ServerBootstrap

Bootstrap 意思是引導，一個 Netty 應用通常由一個 Bootstrap 開始，主要作用是配置整個 Netty 程序，串聯(lián)各個組件，Netty 中 Bootstrap 類是客戶端程序的啟動引導類，ServerBootstrap 是服務(wù)端啟動引導類。

Future、ChannelFuture

正如前面介紹，在 Netty 中所有的 IO 操作都是異步的，不能立刻得知消息是否被正確處理。

但是可以過一會等它執(zhí)行完成或者直接注冊一個監(jiān)聽，具體的實現(xiàn)就是通過 Future 和 ChannelFutures，他們可以注冊一個監(jiān)聽，當操作執(zhí)行成功或失敗時監(jiān)聽會自動觸發(fā)注冊的監(jiān)聽事件。

Channel

Netty 網(wǎng)絡(luò)通信的組件，能夠用于執(zhí)行網(wǎng)絡(luò) I/O 操作。Channel 為用戶提供：

• 當前網(wǎng)絡(luò)連接的通道的狀態(tài)（例如是否打開？是否已連接？）
• 網(wǎng)絡(luò)連接的配置參數(shù) （例如接收緩沖區(qū)大小）
• 提供異步的網(wǎng)絡(luò) I/O 操作(如建立連接，讀寫，綁定端口)，異步調(diào)用意味著任何 I/O 調(diào)用都將立即返回，并且不保證在調(diào)用結(jié)束時所請求的 I/O 操作已完成。

調(diào)用立即返回一個 ChannelFuture 實例，通過注冊監(jiān)聽器到 ChannelFuture 上，可以 I/O 操作成功、失敗或取消時回調(diào)通知調(diào)用方。

• 支持關(guān)聯(lián) I/O 操作與對應的處理程序。

不同協(xié)議、不同的阻塞類型的連接都有不同的 Channel 類型與之對應。下面是一些常用的 Channel 類型：

• NioSocketChannel，異步的客戶端 TCP Socket 連接。
• NioServerSocketChannel，異步的服務(wù)器端 TCP Socket 連接。
• NioDatagramChannel，異步的 UDP 連接。
• NioSctpChannel，異步的客戶端 Sctp 連接。
• NioSctpServerChannel，異步的 Sctp 服務(wù)器端連接，這些通道涵蓋了 UDP 和 TCP 網(wǎng)絡(luò) IO 以及文件 IO。

Selector

Netty 基于 Selector 對象實現(xiàn) I/O 多路復用，通過 Selector 一個線程可以監(jiān)聽多個連接的 Channel 事件。

當向一個 Selector 中注冊 Channel 后，Selector 內(nèi)部的機制就可以自動不斷地查詢(Select) 這些注冊的 Channel 是否有已就緒的 I/O 事件（例如可讀，可寫，網(wǎng)絡(luò)連接完成等），這樣程序就可以很簡單地使用一個線程高效地管理多個 Channel 。

NioEventLoop

NioEventLoop 中維護了一個線程和任務(wù)隊列，支持異步提交執(zhí)行任務(wù)，線程啟動時會調(diào)用 NioEventLoop 的 run 方法，執(zhí)行 I/O 任務(wù)和非 I/O 任務(wù)：

I/O 任務(wù)，即 selectionKey 中 ready 的事件，如 accept、connect、read、write 等，由 processSelectedKeys 方法觸發(fā)。

非 IO 任務(wù)，添加到 taskQueue 中的任務(wù)，如 register0、bind0 等任務(wù)，由 runAllTasks 方法觸發(fā)。

兩種任務(wù)的執(zhí)行時間比由變量 ioRatio 控制，默認為 50，則表示允許非 IO 任務(wù)執(zhí)行的時間與 IO 任務(wù)的執(zhí)行時間相等。

NioEventLoopGroup

NioEventLoopGroup，主要管理 eventLoop 的生命周期，可以理解為一個線程池，內(nèi)部維護了一組線程，每個線程(NioEventLoop)負責處理多個 Channel 上的事件，而一個 Channel 只對應于一個線程。

ChannelHandler

ChannelHandler 是一個接口，處理 I/O 事件或攔截 I/O 操作，并將其轉(zhuǎn)發(fā)到其 ChannelPipeline(業(yè)務(wù)處理鏈)中的下一個處理程序。

ChannelHandler 本身并沒有提供很多方法，因為這個接口有許多的方法需要實現(xiàn)，方便使用期間，可以繼承它的子類：

• ChannelInboundHandler 用于處理入站 I/O 事件。
• ChannelOutboundHandler 用于處理出站 I/O 操作。

或者使用以下適配器類：

• ChannelInboundHandlerAdapter 用于處理入站 I/O 事件。
• ChannelOutboundHandlerAdapter 用于處理出站 I/O 操作。
• ChannelDuplexHandler 用于處理入站和出站事件。

ChannelHandlerContext

保存 Channel 相關(guān)的所有上下文信息，同時關(guān)聯(lián)一個 ChannelHandler 對象。

ChannelPipline

保存 ChannelHandler 的 List，用于處理或攔截 Channel 的入站事件和出站操作。

ChannelPipeline 實現(xiàn)了一種高級形式的攔截過濾器模式，使用戶可以完全控制事件的處理方式，以及 Channel 中各個的 ChannelHandler 如何相互交互。

下圖引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的說明，描述了 ChannelPipeline 中 ChannelHandler 通常如何處理 I/O 事件。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 處理，并通過調(diào)用 ChannelHandlerContext 中定義的事件傳播方法。

例如 ChannelHandlerContext.fireChannelRead（Object）和 ChannelOutboundInvoker.write（Object）轉(zhuǎn)發(fā)到其最近的處理程序。

入站事件由自下而上方向的入站處理程序處理，如圖左側(cè)所示。入站 Handler 處理程序通常處理由圖底部的 I/O 線程生成的入站數(shù)據(jù)。

通常通過實際輸入操作（例如 SocketChannel.read（ByteBuffer））從遠程讀取入站數(shù)據(jù)。

出站事件由上下方向處理，如圖右側(cè)所示。出站 Handler 處理程序通常會生成或轉(zhuǎn)換出站傳輸，例如 write 請求。

I/O 線程通常執(zhí)行實際的輸出操作，例如 SocketChannel.write（ByteBuffer）。

在 Netty 中每個 Channel 都有且僅有一個 ChannelPipeline 與之對應，它們的組成關(guān)系如下：

一個 Channel 包含了一個 ChannelPipeline，而 ChannelPipeline 中又維護了一個由 ChannelHandlerContext 組成的雙向鏈表，并且每個 ChannelHandlerContext 中又關(guān)聯(lián)著一個 ChannelHandler。

入站事件和出站事件在一個雙向鏈表中，入站事件會從鏈表 head 往后傳遞到最后一個入站的 handler，出站事件會從鏈表 tail 往前傳遞到最前一個出站的 handler，兩種類型的 handler 互不干擾。

Netty 工作原理架構(gòu)

初始化并啟動 Netty 服務(wù)端過程如下：

public static void main(String[] args) { 
       // 創(chuàng)建mainReactor 
       NioEventLoopGroup boosGroup = new NioEventLoopGroup(); 
       // 創(chuàng)建工作線程組 
       NioEventLoopGroup workerGroup = new NioEventLoopGroup(); 
 
       final ServerBootstrap serverBootstrap = new ServerBootstrap(); 
       serverBootstrap  
                // 組裝NioEventLoopGroup  
               .group(boosGroup, workerGroup) 
                // 設(shè)置channel類型為NIO類型 
               .channel(NioServerSocketChannel.class) 
               // 設(shè)置連接配置參數(shù) 
               .option(ChannelOption.SO_BACKLOG, 1024) 
               .childOption(ChannelOption.SO_KEEPALIVE, true) 
               .childOption(ChannelOption.TCP_NODELAY, true) 
               // 配置入站、出站事件handler 
               .childHandler(new ChannelInitializer<NioSocketChannel>() { 
                   @Override 
                   protected void initChannel(NioSocketChannel ch) { 
                       // 配置入站、出站事件channel 
                       ch.pipeline().addLast(...); 
                       ch.pipeline().addLast(...); 
                   } 
   }); 
 
       // 綁定端口 
       int port = 8080; 
       serverBootstrap.bind(port).addListener(future -> { 
           if (future.isSuccess()) { 
               System.out.println(new Date() + ": 端口[" + port + "]綁定成功!"); 
           } else { 
               System.err.println("端口[" + port + "]綁定失敗!"); 
           } 
       }); 
} 

基本過程如下：

• 初始化創(chuàng)建 2 個 NioEventLoopGroup，其中 boosGroup 用于 Accetpt 連接建立事件并分發(fā)請求，workerGroup 用于處理 I/O 讀寫事件和業(yè)務(wù)邏輯。
• 基于 ServerBootstrap(服務(wù)端啟動引導類)，配置 EventLoopGroup、Channel 類型，連接參數(shù)、配置入站、出站事件 handler。
• 綁定端口，開始工作。

結(jié)合上面介紹的 Netty Reactor 模型，介紹服務(wù)端 Netty 的工作架構(gòu)圖：

服務(wù)端 Netty Reactor 工作架構(gòu)圖

Server 端包含 1 個 Boss NioEventLoopGroup 和 1 個 Worker NioEventLoopGroup。

NioEventLoopGroup 相當于 1 個事件循環(huán)組，這個組里包含多個事件循環(huán) NioEventLoop，每個 NioEventLoop 包含 1 個 Selector 和 1 個事件循環(huán)線程。

每個 Boss NioEventLoop 循環(huán)執(zhí)行的任務(wù)包含 3 步：

• 輪詢 Accept 事件。
• 處理 Accept I/O 事件，與 Client 建立連接，生成 NioSocketChannel，并將 NioSocketChannel 注冊到某個 Worker NioEventLoop 的 Selector 上。
• 處理任務(wù)隊列中的任務(wù)，runAllTasks。任務(wù)隊列中的任務(wù)包括用戶調(diào)用 eventloop.execute 或 schedule 執(zhí)行的任務(wù)，或者其他線程提交到該 eventloop 的任務(wù)。

每個 Worker NioEventLoop 循環(huán)執(zhí)行的任務(wù)包含 3 步：

• 輪詢 Read、Write 事件。
• 處理 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可讀、可寫事件發(fā)生時進行處理。
• 處理任務(wù)隊列中的任務(wù)，runAllTasks。

其中任務(wù)隊列中的 Task 有 3 種典型使用場景。

①用戶程序自定義的普通任務(wù)

ctx.channel().eventLoop().execute(new Runnable() { 
   @Override 
   public void run() { 
       //... 
   } 
}); 

②非當前 Reactor 線程調(diào)用 Channel 的各種方法

例如在推送系統(tǒng)的業(yè)務(wù)線程里面，根據(jù)用戶的標識，找到對應的 Channel 引用，然后調(diào)用 Write 類方法向該用戶推送消息，就會進入到這種場景。最終的 Write 會提交到任務(wù)隊列中后被異步消費。

③用戶自定義定時任務(wù)

ctx.channel().eventLoop().schedule(new Runnable() { 
   @Override 
   public void run() { 
 
   } 
}, 60, TimeUnit.SECONDS); 

總結(jié)

現(xiàn)在穩(wěn)定推薦使用的主流版本還是 Netty4，Netty5 中使用了 ForkJoinPool，增加了代碼的復雜度，但是對性能的改善卻不明顯，所以這個版本不推薦使用，官網(wǎng)也沒有提供下載鏈接。

Netty 入門門檻相對較高，是因為這方面的資料較少，并不是因為它有多難，大家其實都可以像搞透 Spring 一樣搞透 Netty。

在學習之前，建議先理解透整個框架原理結(jié)構(gòu)，運行過程，可以少走很多彎路。

參考資料：

• Netty入門與實戰(zhàn)：仿寫微信 IM 即時通訊系統(tǒng)
• Netty官網(wǎng)
• Netty 4.x學習筆記 - 線程模型
• Netty入門與實戰(zhàn)
• 理解高性能網(wǎng)絡(luò)模型
• Netty基本原理介紹
• software-architecture-patterns.pdf
• Netty高性能之道 —— 李林鋒
• 《Netty In Action》
• 《Netty權(quán)威指南》

陳彩華(caison)，從事服務(wù)端開發(fā)，善于系統(tǒng)設(shè)計、優(yōu)化重構(gòu)、線上問題排查工作，主要開發(fā)語言是 Java，微信號：hua1881375。