想了解AIO,BIO NIO Reactor 請參考：IO復用,AIO,BIO,NIO,同步，異步，阻塞和非阻塞 區別(百度)
1、引言
Netty 是一個廣受歡迎的異步事件驅動的Java開源網絡應用程序框架，用於快速開發可維護的高性能協議服務器和客戶端。
本文基於 Netty 4.1 展開介紹相關理論模型，使用場景，基本組件、整體架構，知其然且知其所以然，希望給大家在實際開發實踐、學習開源項目方面提供參考。
本文作者的另兩篇《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》、《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》也寫的很好，有興趣的讀者可以一並看看。
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的其它精華文章：
《開源NIO框架八卦——到底是先有MINA還是先有Netty?》
《Netty 4.x學習（二）：Channel和Pipeline詳解》
《實踐總結：Netty3.x升級Netty4.x遇到的那些坑（線程篇）》
《實踐總結：Netty3.x VS Netty4.x的線程模型》
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 特性、優缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》、《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》。
【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(...);
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() {
@Override
publicvoidrun() {
}
}, 60, TimeUnit.SECONDS);
9、本文小結
現在推薦使用的主流穩定版本還是 Netty4，Netty5 中使用了 ForkJoinPool，增加了代碼的復雜度，但是對性能的改善卻不明顯，所以這個版本不推薦使用，官網也沒有提供下載鏈接。
Netty 入門門檻相對較高，是因為這方面的資料較少，並不是因為它有多難，大家其實都可以像搞透 Spring 一樣搞透 Netty。
在學習之前，建議先理解透整個框架原理結構，運行過程，可以少走很多彎路。
Netty到底是什么
從HTTP說起
有了Netty，你可以實現自己的HTTP服務器，FTP服務器，UDP服務器，RPC服務器，WebSocket服務器，Redis的Proxy服務器，MySQL的Proxy服務器等等。
我們回顧一下傳統的HTTP服務器的原理
1、創建一個ServerSocket，監聽並綁定一個端口
2、一系列客戶端來請求這個端口
3、服務器使用Accept，獲得一個來自客戶端的Socket連接對象
4、啟動一個新線程處理連接
4.1、讀Socket，得到字節流
4.2、解碼協議，得到Http請求對象
4.3、處理Http請求，得到一個結果，封裝成一個HttpResponse對象
4.4、編碼協議，將結果序列化字節流 寫Socket，將字節流發給客戶端
5、繼續循環步驟3
HTTP服務器之所以稱為HTTP服務器，是因為編碼解碼協議是HTTP協議，如果協議是Redis協議，那它就成了Redis服務器，如果協議是WebSocket，那它就成了WebSocket服務器，等等。 使用Netty你就可以定制編解碼協議，實現自己的特定協議的服務器。
NIO
上面是一個傳統處理http的服務器，但是在高並發的環境下，線程數量會比較多，System load也會比較高，於是就有了NIO。
他並不是Java獨有的概念，NIO代表的一個詞匯叫着IO多路復用。它是由操作系統提供的系統調用，早期這個操作系統調用的名字是select，但是性能低下，后來漸漸演化成了Linux下的epoll和Mac里的kqueue。我們一般就說是epoll，因為沒有人拿蘋果電腦作為服務器使用對外提供服務。而Netty就是基於Java NIO技術封裝的一套框架。為什么要封裝，因為原生的Java NIO使用起來沒那么方便，而且還有臭名昭著的bug，Netty把它封裝之后，提供了一個易於操作的使用模式和接口，用戶使用起來也就便捷多了。
說NIO之前先說一下BIO（Blocking IO）,如何理解這個Blocking呢？
客戶端監聽（Listen）時，Accept是阻塞的，只有新連接來了，Accept才會返回，主線程才能繼
讀寫socket時，Read是阻塞的，只有請求消息來了，Read才能返回，子線程才能繼續處理
讀寫socket時，Write是阻塞的，只有客戶端把消息收了，Write才能返回，子線程才能繼續讀取下一個請求
傳統的BIO模式下，從頭到尾的所有線程都是阻塞的，這些線程就干等着，占用系統的資源，什么事也不干。
那么NIO是怎么做到非阻塞的呢。它用的是事件機制。它可以用一個線程把Accept，讀寫操作，請求處理的邏輯全干了。如果什么事都沒得做，它也不會死循環，它會將線程休眠起來，直到下一個事件來了再繼續干活，這樣的一個線程稱之為NIO線程。用偽代碼表示：
while true { events = takeEvents(fds) // 獲取事件，如果沒有事件，線程就休眠 for event in events { if event.isAcceptable { doAccept() // 新鏈接來了 } elif event.isReadable { request = doRead() // 讀消息 if request.isComplete() { doProcess() } } elif event.isWriteable { doWrite() // 寫消息 } } }
Reactor線程模型
Reactor單線程模型
一個NIO線程+一個accept線程：
Reactor多線程模型
Reactor主從模型
主從Reactor多線程：多個acceptor的NIO線程池用於接受客戶端的連接
Netty可以基於如上三種模型進行靈活的配置。
總結
Netty是建立在NIO基礎之上，Netty在NIO之上又提供了更高層次的抽象。
在Netty里面，Accept連接可以使用單獨的線程池去處理，讀寫操作又是另外的線程池來處理。
Accept連接和讀寫操作也可以使用同一個線程池來進行處理。而請求處理邏輯既可以使用單獨的線程池進行處理，也可以跟放在讀寫線程一塊處理。線程池中的每一個線程都是NIO線程。用戶可以根據實際情況進行組裝，構造出滿足系統需求的高性能並發模型。
為什么選擇Netty
如果不用netty，使用原生JDK的話，有如下問題：
1、API復雜
2、對多線程很熟悉：因為NIO涉及到Reactor模式
3、高可用的話：需要出路斷連重連、半包讀寫、失敗緩存等問題
4、JDK NIO的bug
而Netty來說，他的api簡單、性能高而且社區活躍（dubbo、rocketmq等都使用了它）
什么是TCP 粘包/拆包
現象
先看如下代碼，這個代碼是使用netty在client端重復寫100次數據給server端，ByteBuf是netty的一個字節容器，里面存放是的需要發送的數據
public class FirstClientHandler extends ChannelInboundHandlerAdapter { @Override public void channelActive(ChannelHandlerContext ctx) { for (int i = 0; i < 1000; i++) { ByteBuf buffer = getByteBuf(ctx); ctx.channel().writeAndFlush(buffer); } } private ByteBuf getByteBuf(ChannelHandlerContext ctx) { byte[] bytes = "需要更多資料加群：586446657".getBytes(Charset.forName("utf-8")); ByteBuf buffer = ctx.alloc().buffer(); buffer.writeBytes(bytes); return buffer; } }
從client端讀取到的數據為：
從服務端的控制台輸出可以看出，存在三種類型的輸出
一種是正常的字符串輸出。
一種是多個字符串“粘”在了一起，我們定義這種 ByteBuf 為粘包。
一種是一個字符串被“拆”開，形成一個破碎的包，我們定義這種 ByteBuf 為半包。
透過現象分析原因
應用層面使用了Netty，但是對於操作系統來說，只認TCP協議，盡管我們的應用層是按照 ByteBuf 為 單位來發送數據，server按照Bytebuf讀取，但是到了底層操作系統仍然是按照字節流發送數據，因此，數據到了服務端，也是按照字節流的方式讀入，然后到了 Netty 應用層面，重新拼裝成 ByteBuf，而這里的 ByteBuf 與客戶端按順序發送的 ByteBuf 可能是不對等的。因此，我們需要在客戶端根據自定義協議來組裝我們應用層的數據包，然后在服務端根據我們的應用層的協議來組裝數據包，這個過程通常在服務端稱為拆包，而在客戶端稱為粘包。
拆包和粘包是相對的，一端粘了包，另外一端就需要將粘過的包拆開，發送端將三個數據包粘成兩個 TCP 數據包發送到接收端，接收端就需要根據應用協議將兩個數據包重新組裝成三個數據包。
如何解決
在沒有 Netty 的情況下，用戶如果自己需要拆包，基本原理就是不斷從 TCP 緩沖區中讀取數據，每次讀取完都需要判斷是否是一個完整的數據包 如果當前讀取的數據不足以拼接成一個完整的業務數據包，那就保留該數據，繼續從 TCP 緩沖區中讀取，直到得到一個完整的數據包。 如果當前讀到的數據加上已經讀取的數據足夠拼接成一個數據包，那就將已經讀取的數據拼接上本次讀取的數據，構成一個完整的業務數據包傳遞到業務邏輯，多余的數據仍然保留，以便和下次讀到的數據嘗試拼接。
而在Netty中，已經造好了許多類型的拆包器，我們直接用就好：
選好拆包器后，在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:
如上實例中：
客戶端：
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));服務端：
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));
Netty 的零拷貝
傳統意義的拷貝
是在發送數據的時候，傳統的實現方式是：
File.read(bytes)Socket.send(bytes)
這種方式需要四次數據拷貝和四次上下文切換：
- 數據從磁盤讀取到內核的read buffer
- 數據從內核緩沖區拷貝到用戶緩沖區
- 數據從用戶緩沖區拷貝到內核的socket buffer
- 數據從內核的socket buffer拷貝到網卡接口（硬件）的緩沖區
零拷貝的概念
明顯上面的第二步和第三步是沒有必要的，通過java的FileChannel.transferTo方法，可以避免上面兩次多余的拷貝（當然這需要底層操作系統支持）
- 調用transferTo,數據從文件由DMA引擎拷貝到內核read buffer
- 接着DMA從內核read buffer將數據拷貝到網卡接口buffer
上面的兩次操作都不需要CPU參與，所以就達到了零拷貝。
Netty中的零拷貝
主要體現在三個方面：
1、bytebuffer
Netty發送和接收消息主要使用bytebuffer，bytebuffer使用對外內存（DirectMemory）直接進行Socket讀寫。
原因：如果使用傳統的堆內存進行Socket讀寫，JVM會將堆內存buffer拷貝一份到直接內存中然后再寫入socket，多了一次緩沖區的內存拷貝。DirectMemory中可以直接通過DMA發送到網卡接口
2、Composite Buffers
傳統的ByteBuffer，如果需要將兩個ByteBuffer中的數據組合到一起，我們需要首先創建一個size=size1+size2大小的新的數組，然后將兩個數組中的數據拷貝到新的數組中。但是使用Netty提供的組合ByteBuf，就可以避免這樣的操作，因為CompositeByteBuf並沒有真正將多個Buffer組合起來，而是保存了它們的引用，從而避免了數據的拷貝，實現了零拷貝。
3、對於FileChannel.transferTo的使用
Netty中使用了FileChannel的transferTo方法，該方法依賴於操作系統實現零拷貝。
Netty 內部執行流程
服務端：
1、創建ServerBootStrap實例
2、設置並綁定Reactor線程池：EventLoopGroup，EventLoop就是處理所有注冊到本線程的Selector上面的Channel
3、設置並綁定服務端的channel
4、5、創建處理網絡事件的ChannelPipeline和handler，網絡時間以流的形式在其中流轉，handler完成多數的功能定制：比如編解碼 SSl安全認證
6、綁定並啟動監聽端口
7、當輪訓到准備就緒的channel后，由Reactor線程：NioEventLoop執行pipline中的方法，最終調度並執行channelHandler
客戶端
總結
以上就是我對Netty相關知識整理，如果有不同的見解，歡迎討論！