1、引言
Netty是一個廣受歡迎的異步事件驅動的Java開源網絡應用程式架構，用于快速開發可維護的高性能協定伺服器和用戶端。
本文基于
Netty 4.1展開介紹相關理論模型，使用場景，基本元件、整體架構，知其然且知其是以然，希望給大家在實際開發實踐、學習開源項目方面提供參考。
本文作者的另兩篇《
高性能網絡程式設計(五)：一文讀懂高性能網絡程式設計中的I/O模型》、《
高性能網絡程式設計(六)：一文讀懂高性能網絡程式設計中的線程模型》也寫的很好，有興趣的讀者可以一并看看。
關于作者：
陳彩華(caison)，從事服務端開發，善于系統設計、優化重構、線上問題排查工作，主要開發語言是 Java，微信号：hua1881375。
（本文同步釋出于：
http://www.52im.net/thread-2043-1-1.html）
2、相關資料
Netty源碼線上閱讀：
Netty-4.1.x位址是： http://docs.52im.net/extend/docs/src/netty4_1/ Netty-4.0.x位址是： http://docs.52im.net/extend/docs/src/netty4/ Netty-3.x位址是： http://docs.52im.net/extend/docs/src/netty3/
Netty線上API文檔：
Netty-4.1.x API文檔(線上版)： http://docs.52im.net/extend/docs/api/netty4_1/ Netty-4.0.x API文檔(線上版)： http://docs.52im.net/extend/docs/api/netty4/ Netty-3.x API文檔(線上版)： http://docs.52im.net/extend/docs/api/netty3/
有關Netty的其它精華文章：
《 有關“為何選擇Netty”的11個疑問及解答 》 開源NIO架構八卦——到底是先有MINA還是先有Netty? 選Netty還是Mina：深入研究與對比（一） 選Netty還是Mina：深入研究與對比（二） Netty 4.x學習（一）：ByteBuf詳解 Netty 4.x學習（二）：Channel和Pipeline詳解 Netty 4.x學習（三）：線程模型詳解 實踐總結：Netty3.x更新Netty4.x遇到的那些坑（線程篇） 實踐總結：Netty3.x VS Netty4.x的線程模型 詳解Netty的安全性：原理介紹、代碼示範（上篇） 詳解Netty的安全性：原理介紹、代碼示範（下篇） 詳解Netty的優雅退出機制和原理 NIO架構詳解：Netty的高性能之道 Twitter：如何使用Netty 4來減少JVM的GC開銷（譯文） 絕對幹貨：基于Netty實作海量接入的推送服務技術要點 Netty幹貨分享：京東京麥的生産級TCP網關技術實踐總結
3、JDK 原生 NIO 程式的問題
JDK 原生也有一套網絡應用程式 API，但是存在一系列問題，主要如下：
1）NIO 的類庫和 API 繁雜，使用麻煩：你需要熟練掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
2）需要具備其他的額外技能做鋪墊：例如熟悉 Java 多線程程式設計，因為 NIO 程式設計涉及到 Reactor 模式，你必須對多線程和網路程式設計非常熟悉，才能編寫出高品質的 NIO 程式。
3）可靠性能力補齊，開發工作量和難度都非常大：例如用戶端面臨斷連重連、網絡閃斷、半包讀寫、失敗緩存、網絡擁塞和異常碼流的處理等等。NIO 程式設計的特點是功能開發相對容易，但是可靠性能力補齊工作量和難度都非常大。
4）JDK NIO 的 Bug：例如臭名昭著的 Epoll Bug，它會導緻 Selector 空輪詢，最終導緻 CPU 100%。官方聲稱在 JDK 1.6 版本的 update 18 修複了該問題，但是直到 JDK 1.7 版本該問題仍舊存在，隻不過該 Bug 發生機率降低了一些而已，它并沒有被根本解決。
4、Netty 的特點
Netty 對 JDK 自帶的 NIO 的 API 進行了封裝，解決了上述問題。
Netty的主要特點有：
1）設計優雅：适用于各種傳輸類型的統一 API 阻塞和非阻塞 Socket；基于靈活且可擴充的事件模型，可以清晰地分離關注點；高度可定制的線程模型 - 單線程，一個或多個線程池；真正的無連接配接資料報套接字支援（自 3.1 起）。
2）使用友善：詳細記錄的 Javadoc，使用者指南和示例；沒有其他依賴項，JDK 5（Netty 3.x）或 6（Netty 4.x）就足夠了。
3）高性能、吞吐量更高：延遲更低；減少資源消耗；最小化不必要的記憶體複制。
4）安全：完整的 SSL/TLS 和 StartTLS 支援。
5）社群活躍、不斷更新：社群活躍，版本疊代周期短，發現的 Bug 可以被及時修複，同時，更多的新功能會被加入。
5、Netty 常見使用場景
Netty 常見的使用場景如下：
1）網際網路行業：在分布式系統中，各個節點之間需要遠端服務調用，高性能的 RPC 架構必不可少，Netty 作為異步高性能的通信架構，往往作為基礎通信元件被這些 RPC 架構使用。典型的應用有：阿裡分布式服務架構 Dubbo 的 RPC 架構使用 Dubbo 協定進行節點間通信，Dubbo 協定預設使用 Netty 作為基礎通信元件，用于實作各程序節點之間的内部通信。
2）遊戲行業：無論是手遊服務端還是大型的網絡遊戲，Java 語言得到了越來越廣泛的應用。Netty 作為高性能的基礎通信元件，它本身提供了 TCP/UDP 和 HTTP 協定棧。
非常友善定制和開發私有協定棧，賬号登入伺服器，地圖伺服器之間可以友善的通過 Netty 進行高性能的通信。
3）大資料領域：經典的 Hadoop 的高性能通信和序列化元件 Avro 的 RPC 架構，預設采用 Netty 進行跨界點通信，它的 Netty Service 基于 Netty 架構二次封裝實作。
有興趣的讀者可以了解一下目前有哪些開源項目使用了
Netty的Related Projects。
6、Netty 高性能設計
Netty 作為異步事件驅動的網絡，高性能之處主要來自于其 I/O 模型和線程處理模型，前者決定如何收發資料，後者決定如何處理資料。
6.1 I/O 模型
用什麼樣的通道将資料發送給對方，
BIO、NIO 或者 AIO，I/O 模型在很大程度上決定了架構的性能。
【阻塞 I/O】：
傳統阻塞型 I/O(BIO)可以用下圖表示：
特點如下：
每個請求都需要獨立的線程完成資料 Read，業務處理，資料 Write 的完整操作問題。
當并發數較大時，需要建立大量線程來處理連接配接，系統資源占用較大。
連接配接建立後，如果目前線程暫時沒有資料可讀，則線程就阻塞在 Read 操作上，造成線程資源浪費。
【I/O 複用模型】：
在 I/O 複用模型中，會用到 Select，這個函數也會使程序阻塞，但是和阻塞 I/O 所不同的是這兩個函數可以同時阻塞多個 I/O 操作。
而且可以同時對多個讀操作，多個寫操作的 I/O 函數進行檢測，直到有資料可讀或可寫時，才真正調用 I/O 操作函數。
Netty 的非阻塞 I/O 的實作關鍵是基于 I/O 複用模型，這裡用 Selector 對象表示：
Netty 的 IO 線程 NioEventLoop 由于聚合了多路複用器 Selector，可以同時并發處理成百上千個用戶端連接配接。
當線程從某用戶端 Socket 通道進行讀寫資料時，若沒有資料可用時，該線程可以進行其他任務。
線程通常将非阻塞 IO 的空閑時間用于在其他通道上執行 IO 操作，是以單獨的線程可以管理多個輸入和輸出通道。
由于讀寫操作都是非阻塞的，這就可以充分提升 IO 線程的運作效率，避免由于頻繁 I/O 阻塞導緻的線程挂起。
一個 I/O 線程可以并發處理 N 個用戶端連接配接和讀寫操作，這從根本上解決了傳統同步阻塞 I/O 一連接配接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。
【基于 Buffer】：
傳統的 I/O 是面向位元組流或字元流的，以流式的方式順序地從一個 Stream 中讀取一個或多個位元組, 是以也就不能随意改變讀取指針的位置。
在 NIO 中，抛棄了傳統的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，隻能從 Channel 中讀取資料到 Buffer 中或将資料從 Buffer 中寫入到 Channel。
基于 Buffer 操作不像傳統 IO 的順序操作，NIO 中可以随意地讀取任意位置的資料。
6.2 線程模型
資料報如何讀取？讀取之後的編解碼在哪個線程進行，編解碼後的消息如何派發，線程模型的不同，對性能的影響也非常大。
【事件驅動模型】：
通常，我們設計一個事件處理模型的程式有兩種思路：
1）輪詢方式：線程不斷輪詢通路相關事件發生源有沒有發生事件，有發生事件就調用事件處理邏輯；
2）事件驅動方式：發生事件，主線程把事件放入事件隊列，在另外線程不斷循環消費事件清單中的事件，調用事件對應的處理邏輯處理事件。事件驅動方式也被稱為消息通知方式，其實是設計模式中觀察者模式的思路。
以 GUI 的邏輯處理為例，說明兩種邏輯的不同：
1）輪詢方式：線程不斷輪詢是否發生按鈕點選事件，如果發生，調用處理邏輯。
2）事件驅動方式：發生點選事件把事件放入事件隊列，在另外線程消費的事件清單中的事件，根據事件類型調用相關事件處理邏輯。
這裡借用 O'Reilly 大神關于事件驅動模型解釋圖：
主要包括 4 個基本元件：
1）事件隊列（event queue）：接收事件的入口，存儲待處理事件；
2）分發器（event mediator）：将不同的事件分發到不同的業務邏輯單元；
3）事件通道（event channel）：分發器與處理器之間的聯系管道；
4）事件處理器（event processor）：實作業務邏輯，處理完成後會發出事件，觸發下一步操作。
可以看出，相對傳統輪詢模式，事件驅動有如下優點：
1）可擴充性好：分布式的異步架構，事件處理器之間高度解耦，可以友善擴充事件處理邏輯；
2）高性能：基于隊列暫存事件，能友善并行異步處理事件。
【Reactor 線程模型】：
Reactor 是反應堆的意思，Reactor 模型是指通過一個或多個輸入同時傳遞給服務處理器的服務請求的事件驅動處理模式。
服務端程式處理傳入多路請求，并将它們同步分派給請求對應的處理線程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了複用統一監聽事件，收到事件後分發(Dispatch 給某程序)，是編寫高性能網絡伺服器的必備技術之一。
Reactor 模型中有 2 個關鍵組成：
1）Reactor：Reactor 在一個單獨的線程中運作，負責監聽和分發事件，分發給适當的處理程式來對 IO 事件做出反應。它就像公司的電話接線員，它接聽來自客戶的電話并将線路轉移到适當的聯系人；
2）Handlers：處理程式執行 I/O 事件要完成的實際事件，類似于客戶想要與之交談的公司中的實際官員。Reactor 通過排程适當的處理程式來響應 I/O 事件，處理程式執行非阻塞操作。
取決于 Reactor 的數量和 Hanndler 線程數量的不同，Reactor 模型有 3 個變種：
1）單 Reactor 單線程；
2）單 Reactor 多線程；
3）主從 Reactor 多線程。
可以這樣了解，Reactor 就是一個執行 while (true) { selector.select(); …} 循環的線程，會源源不斷的産生新的事件，稱作反應堆很貼切。
篇幅關系，這裡不再具體展開 Reactor 特性、優缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《
》。
【Netty 線程模型】：
Netty 主要基于主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：
1）MainReactor 負責用戶端的連接配接請求，并将請求轉交給 SubReactor；
2）SubReactor 負責相應通道的 IO 讀寫請求；
3）非 IO 請求（具體邏輯處理）的任務則會直接寫入隊列，等待 worker threads 進行處理。
這裡引用 Doug Lee 大神的 Reactor 介紹——Scalable IO in Java 裡面關于主從 Reactor 多線程模型的圖：
特别說明的是：雖然 Netty 的線程模型基于主從 Reactor 多線程，借用了 MainReactor 和 SubReactor 的結構。但是實際實作上 SubReactor 和 Worker 線程在同一個線程池中：
EventLoopGroup bossGroup = newNioEventLoopGroup();
EventLoopGroup workerGroup = newNioEventLoopGroup();
ServerBootstrap server = newServerBootstrap();
server.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
上面代碼中的 bossGroup 和 workerGroup 是 Bootstrap 構造方法中傳入的兩個對象，這兩個 group 均是線程池：
1）bossGroup 線程池則隻是在 Bind 某個端口後，獲得其中一個線程作為 MainReactor，專門處理端口的 Accept 事件，每個端口對應一個 Boss 線程；
2）workerGroup 線程池會被各個 SubReactor 和 Worker 線程充分利用。
【異步處理】：
異步的概念和同步相對。當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀态、通知和回調來通知調用者。
Netty 中的 I/O 操作是異步的，包括 Bind、Write、Connect 等操作會簡單的傳回一個 ChannelFuture。
調用者并不能立刻獲得結果，而是通過 Future-Listener 機制，使用者可以友善的主動擷取或者通過通知機制獲得 IO 操作結果。
當 Future 對象剛剛建立時，處于非完成狀态，調用者可以通過傳回的 ChannelFuture 來擷取操作執行的狀态，注冊監聽函數來執行完成後的操作。
常見有如下操作：
1）通過 isDone 方法來判斷目前操作是否完成；
2）通過 isSuccess 方法來判斷已完成的目前操作是否成功；
3）通過 getCause 方法來擷取已完成的目前操作失敗的原因；
4）通過 isCancelled 方法來判斷已完成的目前操作是否被取消；
5）通過 addListener 方法來注冊監聽器，當操作已完成(isDone 方法傳回完成)，将會通知指定的監聽器；如果 Future 對象已完成，則了解通知指定的監聽器。
例如下面的代碼中綁定端口是異步操作，當綁定操作處理完，将會調用相應的監聽器處理邏輯：
serverBootstrap.bind(port).addListener(future -> {
if(future.isSuccess()) {
System.out.println(newDate() + ": 端口["+ port + "]綁定成功!");
} else{
System.err.println("端口["+ port + "]綁定失敗!");
}
});
相比傳統阻塞 I/O，執行 I/O 操作後線程會被阻塞住, 直到操作完成；異步處理的好處是不會造成線程阻塞，線程在 I/O 操作期間可以執行别的程式，在高并發情形下會更穩定和更高的吞吐量。
7、Netty架構的架構設計
前面介紹完 Netty 相關一些理論，下面從功能特性、子產品元件、運作過程來介紹 Netty 的架構設計。
7.1 功能特性
Netty 功能特性如下：
1）傳輸服務：支援 BIO 和 NIO；
2）容器內建：支援 OSGI、JBossMC、Spring、Guice 容器；
3）協定支援：HTTP、Protobuf、二進制、文本、WebSocket 等一系列常見協定都支援。還支援通過實行編碼解碼邏輯來實作自定義協定；
4）Core 核心：可擴充事件模型、通用通信 API、支援零拷貝的 ByteBuf 緩沖對象。
7.2 子產品元件
【Bootstrap、ServerBootstrap】：
Bootstrap 意思是引導，一個 Netty 應用通常由一個 Bootstrap 開始，主要作用是配置整個 Netty 程式，串聯各個元件，Netty 中 Bootstrap 類是用戶端程式的啟動引導類，ServerBootstrap 是服務端啟動引導類。
【Future、ChannelFuture】：
正如前面介紹，在 Netty 中所有的 IO 操作都是異步的，不能立刻得知消息是否被正确處理。
但是可以過一會等它執行完成或者直接注冊一個監聽，具體的實作就是通過 Future 和 ChannelFutures，他們可以注冊一個監聽，當操作執行成功或失敗時監聽會自動觸發注冊的監聽事件。
【Channel】：
Netty 網絡通信的元件，能夠用于執行網絡 I/O 操作。Channel 為使用者提供：
1）目前網絡連接配接的通道的狀态（例如是否打開？是否已連接配接？）
2）網絡連接配接的配置參數 （例如接收緩沖區大小）
3）提供異步的網絡 I/O 操作(如建立連接配接，讀寫，綁定端口)，異步調用意味着任何 I/O 調用都将立即傳回，并且不保證在調用結束時所請求的 I/O 操作已完成。
4）調用立即傳回一個 ChannelFuture 執行個體，通過注冊監聽器到 ChannelFuture 上，可以 I/O 操作成功、失敗或取消時回調通知調用方。
5）支援關聯 I/O 操作與對應的處理程式。
不同協定、不同的阻塞類型的連接配接都有不同的 Channel 類型與之對應。
下面是一些常用的 Channel 類型：
NioSocketChannel，異步的用戶端 TCP Socket 連接配接。
NioServerSocketChannel，異步的伺服器端 TCP Socket 連接配接。
NioDatagramChannel，異步的 UDP 連接配接。
NioSctpChannel，異步的用戶端 Sctp 連接配接。
NioSctpServerChannel，異步的 Sctp 伺服器端連接配接，這些通道涵蓋了 UDP 和 TCP 網絡 IO 以及檔案 IO。
【Selector】：
Netty 基于 Selector 對象實作 I/O 多路複用，通過 Selector 一個線程可以監聽多個連接配接的 Channel 事件。
當向一個 Selector 中注冊 Channel 後，Selector 内部的機制就可以自動不斷地查詢(Select) 這些注冊的 Channel 是否有已就緒的 I/O 事件（例如可讀，可寫，網絡連接配接完成等），這樣程式就可以很簡單地使用一個線程高效地管理多個 Channel 。
【NioEventLoop】：
NioEventLoop 中維護了一個線程和任務隊列，支援異步送出執行任務，線程啟動時會調用 NioEventLoop 的 run 方法，執行 I/O 任務和非 I/O 任務：
I/O 任務，即 selectionKey 中 ready 的事件，如 accept、connect、read、write 等，由 processSelectedKeys 方法觸發。
非 IO 任務，添加到 taskQueue 中的任務，如 register0、bind0 等任務，由 runAllTasks 方法觸發。
兩種任務的執行時間比由變量 ioRatio 控制，預設為 50，則表示允許非 IO 任務執行的時間與 IO 任務的執行時間相等。
【NioEventLoopGroup】：
NioEventLoopGroup，主要管理 eventLoop 的生命周期，可以了解為一個線程池，内部維護了一組線程，每個線程(NioEventLoop)負責處理多個 Channel 上的事件，而一個 Channel 隻對應于一個線程。
【ChannelHandler】：
ChannelHandler 是一個接口，處理 I/O 事件或攔截 I/O 操作，并将其轉發到其 ChannelPipeline(業務處理鍊)中的下一個處理程式。
ChannelHandler 本身并沒有提供很多方法，因為這個接口有許多的方法需要實作，友善使用期間，可以繼承它的子類：
ChannelInboundHandler 用于處理入站 I/O 事件。
ChannelOutboundHandler 用于處理出站 I/O 操作。
或者使用以下擴充卡類：
ChannelInboundHandlerAdapter 用于處理入站 I/O 事件。
ChannelOutboundHandlerAdapter 用于處理出站 I/O 操作。
ChannelDuplexHandler 用于處理入站和出站事件。
【ChannelHandlerContext】：
儲存 Channel 相關的所有上下文資訊，同時關聯一個 ChannelHandler 對象。
【ChannelPipline】：
儲存 ChannelHandler 的 List，用于處理或攔截 Channel 的入站事件和出站操作。
ChannelPipeline 實作了一種進階形式的攔截過濾器模式，使使用者可以完全控制事件的處理方式，以及 Channel 中各個的 ChannelHandler 如何互相互動。
下圖引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的說明，描述了 ChannelPipeline 中 ChannelHandler 通常如何處理 I/O 事件。
I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 處理，并通過調用 ChannelHandlerContext 中定義的事件傳播方法。
例如：ChannelHandlerContext.fireChannelRead（Object）和 ChannelOutboundInvoker.write（Object）轉發到其最近的處理程式。
入站事件由自下而上方向的入站處理程式處理，如圖左側所示。入站 Handler 處理程式通常處理由圖底部的 I/O 線程生成的入站資料。
通常通過實際輸入操作（例如 SocketChannel.read（ByteBuffer））從遠端讀取入站資料。
出站事件由上下方向處理，如圖右側所示。出站 Handler 處理程式通常會生成或轉換出站傳輸，例如 write 請求。
I/O 線程通常執行實際的輸出操作，例如 SocketChannel.write（ByteBuffer）。
在 Netty 中每個 Channel 都有且僅有一個 ChannelPipeline 與之對應，它們的組成關系如下：
一個 Channel 包含了一個 ChannelPipeline，而 ChannelPipeline 中又維護了一個由 ChannelHandlerContext 組成的雙向連結清單，并且每個 ChannelHandlerContext 中又關聯着一個 ChannelHandler。
入站事件和出站事件在一個雙向連結清單中，入站事件會從連結清單 head 往後傳遞到最後一個入站的 handler，出站事件會從連結清單 tail 往前傳遞到最前一個出站的 handler，兩種類型的 handler 互不幹擾。
8、Netty架構的工作原理
典型的初始化并啟動 Netty 服務端的過程代碼如下：
publicstaticvoidmain(String[] args) {
// 建立mainReactor
NioEventLoopGroup boosGroup = newNioEventLoopGroup();
// 建立工作線程組
NioEventLoopGroup workerGroup = newNioEventLoopGroup();
finalServerBootstrap serverBootstrap = newServerBootstrap();
serverBootstrap
// 組裝NioEventLoopGroup
.group(boosGroup, workerGroup)
// 設定channel類型為NIO類型
.channel(NioServerSocketChannel.class)
// 設定連接配接配置參數
.option(ChannelOption.SO_BACKLOG, 1024)
.childOption(ChannelOption.SO_KEEPALIVE, true)
.childOption(ChannelOption.TCP_NODELAY, true)
// 配置入站、出站事件handler
.childHandler(newChannelInitializer<NioSocketChannel>() {
@Override
protectedvoidinitChannel(NioSocketChannel ch) {
// 配置入站、出站事件channel
ch.pipeline().addLast(...);
}
// 綁定端口
intport = 8080;
serverBootstrap.bind(port).addListener(future -> {
if(future.isSuccess()) {
System.out.println(newDate() + ": 端口["+ port + "]綁定成功!");
} else{
System.err.println("端口["+ port + "]綁定失敗!");
}
});
}
基本過程描述如下：
1）初始化建立 2 個 NioEventLoopGroup：其中 boosGroup 用于 Accetpt 連接配接建立事件并分發請求，workerGroup 用于處理 I/O 讀寫事件和業務邏輯。
2）基于 ServerBootstrap(服務端啟動引導類)：配置 EventLoopGroup、Channel 類型，連接配接參數、配置入站、出站事件 handler。
3）綁定端口：開始工作。
結合上面介紹的 Netty Reactor 模型，介紹服務端 Netty 的工作架構圖：
Server 端包含 1 個 Boss NioEventLoopGroup 和 1 個 Worker NioEventLoopGroup。
NioEventLoopGroup 相當于 1 個事件循環組，這個組裡包含多個事件循環 NioEventLoop，每個 NioEventLoop 包含 1 個 Selector 和 1 個事件循環線程。
每個 Boss NioEventLoop 循環執行的任務包含 3 步：
1）輪詢 Accept 事件；
2）處理 Accept I/O 事件，與 Client 建立連接配接，生成 NioSocketChannel，并将 NioSocketChannel 注冊到某個 Worker NioEventLoop 的 Selector 上；
3）處理任務隊列中的任務，runAllTasks。任務隊列中的任務包括使用者調用 eventloop.execute 或 schedule 執行的任務，或者其他線程送出到該 eventloop 的任務。
每個 Worker NioEventLoop 循環執行的任務包含 3 步：
1）輪詢 Read、Write 事件；
2）處理 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可讀、可寫事件發生時進行處理；
3）處理任務隊列中的任務，runAllTasks。
其中任務隊列中的 Task 有 3 種典型使用場景：
① 使用者程式自定義的普通任務：
ctx.channel().eventLoop().execute(newRunnable() {
@Override
publicvoidrun() {
//...
}
});
② 非目前 Reactor 線程調用 Channel 的各種方法：
例如在推送系統的業務線程裡面，根據使用者的辨別，找到對應的 Channel 引用，然後調用 Write 類方法向該使用者推送消息，就會進入到這種場景。最終的 Write 會送出到任務隊列中後被異步消費。
③ 使用者自定義定時任務：
ctx.channel().eventLoop().schedule(newRunnable() {
}, 60, TimeUnit.SECONDS);
9、本文小結
現在推薦使用的主流穩定版本還是 Netty4，Netty5 中使用了 ForkJoinPool，增加了代碼的複雜度，但是對性能的改善卻不明顯，是以這個版本不推薦使用，官網也沒有提供下載下傳連結。
Netty 入門門檻相對較高，是因為這方面的資料較少，并不是因為它有多難，大家其實都可以像搞透 Spring 一樣搞透 Netty。
在學習之前，建議先了解透整個架構原理結構，運作過程，可以少走很多彎路。
附錄：更多網絡通信方面的文章
[1] 網絡程式設計基礎資料： TCP/IP詳解 - 第11章·UDP：使用者資料報協定 第17章·TCP：傳輸控制協定 第18章·TCP連接配接的建立與終止 第21章·TCP的逾時與重傳 技術往事：改變世界的TCP/IP協定（珍貴多圖、手機慎點） 通俗易懂-深入了解TCP協定（上）：理論基礎 通俗易懂-深入了解TCP協定（下）：RTT、滑動視窗、擁塞處理 理論經典：TCP協定的3次握手與4次揮手過程詳解 理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程 計算機網絡通訊協定關系圖（中文珍藏版） UDP中一個包的大小最大能多大？ P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介 P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解 P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解 通俗易懂：快速了解P2P技術中的NAT穿透原理 高性能網絡程式設計(一)：單台伺服器并發TCP連接配接數到底可以有多少 高性能網絡程式設計(二)：上一個10年，著名的C10K并發連接配接問題 高性能網絡程式設計(三)：下一個10年，是時候考慮C10M并發問題了 高性能網絡程式設計(四)：從C10K到C10M高性能網絡應用的理論探索 不為人知的網絡程式設計(一)：淺析TCP協定中的疑難雜症(上篇) 不為人知的網絡程式設計(二)：淺析TCP協定中的疑難雜症(下篇) 不為人知的網絡程式設計(三)：關閉TCP連接配接時為什麼會TIME_WAIT、CLOSE_WAIT 不為人知的網絡程式設計(四)：深入研究分析TCP的異常關閉 不為人知的網絡程式設計(五)：UDP的連接配接性和負載均衡 不為人知的網絡程式設計(六)：深入地了解UDP協定并用好它 不為人知的網絡程式設計(七)：如何讓不可靠的UDP變的可靠？ 網絡程式設計懶人入門(一)：快速了解網絡通信協定（上篇） 網絡程式設計懶人入門(二)：快速了解網絡通信協定（下篇） 網絡程式設計懶人入門(三)：快速了解TCP協定一篇就夠 網絡程式設計懶人入門(四)：快速了解TCP和UDP的差異 網絡程式設計懶人入門(五)：快速了解為什麼說UDP有時比TCP更有優勢 網絡程式設計懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門 網絡程式設計懶人入門(七)：深入淺出，全面了解HTTP協定 網絡程式設計懶人入門(八)：手把手教你寫基于TCP的Socket長連接配接 技術掃盲：新一代基于UDP的低延時網絡傳輸層協定——QUIC詳解 讓網際網路更快：新一代QUIC協定在騰訊的技術實踐分享 現代移動端網絡短連接配接的優化手段總結：請求速度、弱網适應、安全保障 聊聊iOS中網絡程式設計長連接配接的那些事 移動端IM開發者必讀(一)：通俗易懂，了解移動網絡的“弱”和“慢” 移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結 IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇） IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇） 從HTTP/0.9到HTTP/2：一文讀懂HTTP協定的曆史演變和設計思路 腦殘式網絡程式設計入門(一)：跟着動畫來學TCP三向交握和四次揮手 腦殘式網絡程式設計入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？ 腦殘式網絡程式設計入門(三)：HTTP協定必知必會的一些知識 腦殘式網絡程式設計入門(四)：快速了解HTTP/2的伺服器推送(Server Push) 腦殘式網絡程式設計入門(五)：每天都在用的Ping指令，它到底是什麼？ 以網遊服務端的網絡接入層設計為例，了解實時通信的技術挑戰 邁向高階：優秀Android程式員必知必會的網絡基礎 >> 更多同類文章 …… [2] NIO異步網絡程式設計資料： Java新一代網絡程式設計模型AIO原理及Linux系統AIO介紹 NIO架構入門(一)：服務端基于Netty4的UDP雙向通信Demo示範 NIO架構入門(二)：服務端基于MINA2的UDP雙向通信Demo示範 NIO架構入門(三)：iOS與MINA2、Netty4的跨平台UDP雙向通信實戰 NIO架構入門(四)：Android與MINA2、Netty4的跨平台UDP雙向通信實戰 Apache Mina架構進階篇（一）：IoFilter詳解 Apache Mina架構進階篇（二）：IoHandler詳解 MINA2 線程原理總結（含簡單測試執行個體） Apache MINA2.0 開發指南（中文版）[附件下載下傳] MINA、Netty的源代碼（線上閱讀版）已整理釋出 解決MINA資料傳輸中TCP的粘包、缺包問題（有源碼） 解決Mina中多個同類型Filter執行個體共存的問題
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)