Netty概述

Netty是一個高性能、異步事件驅動的NIO框架，它提供了對TCP、UDP和文件傳輸的支持。作為當前最流行的NIO框架，Netty在互聯網領域、大數據分布式計算領域、游戲行業、通信行業等獲得了廣泛的應用，一些業界著名的開源組件也基于Netty的NIO框架構建。

Netty 利用 Java 高級網絡的能力，隱藏其背后的復雜性而提供一個易于使用的 API 構建一個客戶端/服務端，其具有高并發、傳輸快、封裝好等特點。

高并發

Netty是一款基于NIO（Nonblocking I/O，非阻塞IO）開發的網絡通信框架，對比于BIO（Blocking I/O，阻塞IO），他的并發性能得到了很大提高 。

傳輸快

Netty的傳輸快其實也是依賴了NIO的一個特性——零拷貝。

封裝好

Netty封裝了NIO操作的很多細節，提供易于使用的API，還有心跳、重連機制、拆包粘包方案等特性，使開發者能能夠快速高效的構建一個穩健的高并發應用。

image

Netty框架

Netty項目致力于提供一個異步的、事件驅動的網絡應用框架和工具，用于快速開發可維護的、高性能的、高擴展性的服務器和客戶端之間的協議。換句話說，Netty式一個NIO客戶端服務器框架，能夠快速、輕松地開發網絡應用例如服務器和客戶端間的協議。它簡化了網絡編程如TCP/IP socket服務器。

JBOSSes Netty的設計吸取了大量的協議如FTP、SMTP、HTTP和各種二進制、基于文本的繼承協議等協議的設計經驗，成功地找到了一種方法實現易于開發、性能、穩定、靈活的協議開發。

特征：

Netty為用戶提供了很多創新和更好的網絡開發體驗。

1）設計Design

為各種傳輸類型（塊和非塊socket）提供了統一的API；

建立在靈活和可擴展的事件模型；

高度可定制的線程模式——單線程，一個或多個線程池（如SEDA）；

可信的五連接數據報socket支持。

2）易于使用

良好文檔化的Javadoc、用戶向導和例子；

結構并不臃腫；

無其它的依賴，只需JDK1.5或以上。

3）性能

高吞吐量、低延遲時間；

很小的資源消耗；

最小化不必要的內存復制。

4）健壯性

不會因為快速連接、慢速連接或超載連接引起OutOfMemoryError錯誤；

高速網絡下不會引起NIO程序的讀寫異常。

5）安全

完全支持SSL/TLS和StartTLS；

在Java Applet環境下運行正常。

6）社區

至少每兩周一個版本發布。

項目主頁： http://www.jboss.org/netty/

文檔地址： http://www.jboss.org/netty/documentation.html

下載地址： http://www.jboss.org/netty/downloads.html

為什么選擇Netty

Socket通信（IO/NIO/AIO）編程，對于通信模型已經有了一個基本的認識。我們學習的僅僅是一個模型，如果想把這些真正的用于實際工作中，那么還需要不斷的完善、擴展和優化。比如經典的TCP讀包寫包問題，或者是數據接收的大小，實際的通信處理與應答的處理邏輯等等一些細節問題需要認真的去思考，而這些都需要大量的時間和經歷，以及豐富的經驗。所以想學好Socket通信不是件容易事，那么接下來就來學習一下新的技術Netty，為什么會選擇Netty？因為它簡單！使用Netty不必編寫復雜的邏輯代碼去實現通信，再也不需要去考慮性能問題，不需要考慮編碼問題，半包讀寫等問題。強大的Netty已經幫我們實現好了，我們只需要使用即可。

Netty是最流行的NIO框架，它的健壯性、功能、性能、可定制性和可擴展性在同類框架都是首屈一指的。它已經得到成百上千的商業/商用項目驗證，如Hadoop的RPC框架Avro、RocketMQ以及主流的分布式通信框架Dubbox等等。

image

Netty的線程模型

并發系統可以采用多種并發編程模型來實現。并發模型指定了系統中的線程如何通過協作來完成分配給它們的作業。不同的并發模型采用不同的方式拆分作業，同時線程間的協作和交互方式也不相同。

對于網絡請求一般可以分為兩個處理階段，一是接收請求任務，二是處理網絡請求。根據不同階段處理方式分為以下幾種線程模型：

串行化處理模型

這個模型中用一個線程來處理網絡請求連接和任務處理，當worker接受到一個任務之后，就立刻進行處理，也就是說任務接受和任務處理是在同一個worker線程中進行的，沒有進行區分。這樣做存在一個很大的問題是，必須要等待某個task處理完成之后，才能接受處理下一個task。

而通常情況下，任務的處理過程會比任務的接受流程慢得多。例如在處理任務的時候，我們可能會需要訪問遠程數據庫，這屬于一種網絡IO。通常情況下IO操作是比較耗時的，這直接影響了下一個任務的接受，而且通常在IO操作的時候,CPU是比較空閑的，白白浪費了資源。

因此可以把接收任務和處理任務兩個階段分開處理，一個線程接收任務，放入任務隊列，另外的線程異步處理任務隊列中的任務。

并行化處理模型

由于任務處理一般比較緩慢，會導致任務隊列中任務積壓長時間得不到處理，這時可以使用多線程來處理。這里使用的是一個公共的任務隊列，多線程環境中不免要通過加鎖來保證線程安全，我們常用的線程池就是這種模式。可以通過為每個線程維護一個任務隊列來改進這種模型。

Reactor線程模型

reactor線程模型關注的是：任務接受之后，對處理過程繼續進行切分，劃分為多個不同的步驟，每個步驟用不同的線程來處理，也就是原本由一個線程處理的任務現在由多個線程來處理，每個線程在處理完自己的步驟之后，還需要將任務轉發到下階段線程繼續進行處理。

Netty的Reactor線程模型

其中mainReacotor,subReactor,Thread Pool是三個線程池。mainReactor負責處理客戶端的連接請求，并將accept的連接注冊到subReactor的其中一個線程上；subReactor負責處理客戶端通道上的數據讀寫；Thread Pool是具體的業務邏輯線程池，處理具體業務。

Netty具體線程模型

如何理解NioEventLoop和NioEventLoopGroup

1）NioEventLoop實際上就是工作線程，可以直接理解為一個線程。NioEventLoopGroup是一個線程池，線程池中的線程就是NioEventLoop。

2）實際上bossGroup中有多個NioEventLoop線程，每個NioEventLoop綁定一個端口，也就是說，如果程序只需要監聽1個端口的話，bossGroup里面只需要有一個NioEventLoop線程就行了。

每個NioEventLoop都綁定了一個Selector，所以在Netty的線程模型中，是由多個Selecotr在監聽IO就緒事件。而Channel注冊到Selector。

一個Channel綁定一個NioEventLoop，相當于一個連接綁定一個線程，這個連接所有的ChannelHandler都是在一個線程中執行的，避免了多線程干擾。更重要的是ChannelPipline鏈表必須嚴格按照順序執行的。單線程的設計能夠保證ChannelHandler的順序執行。

一個NioEventLoop的selector可以被多個Channel注冊，也就是說多個Channel共享一個EventLoop。EventLoop的Selecctor對這些Channel進行檢查。

在監聽一個端口的情況下，一個NioEventLoop通過一個NioServerSocketChannel監聽端口，處理TCP連接。后端多個工作線程NioEventLoop處理IO事件。每個Channel綁定一個NioEventLoop線程，1個NioEventLoop線程關聯一個selector來為多個注冊到它的Channel監聽IO就緒事件。NioEventLoop是單線程執行，保證Channel的pipline在單線程中執行，保證了ChannelHandler的執行順序。

小編準備了關于netty的面試題分享給大家，由于文章篇幅原因以下只分享10道netty的面試題。后五道題未設置答案，需要獲取答案和更多Java架構資料、面試題（含答案）和面試心得以及視頻資料的可以加入Java貓的架構學習基地：810589193獲取！

netty面試題

1.BIO、NIO和AIO的區別？

• BIO：一個連接一個線程，客戶端有連接請求時服務器端就需要啟動一個線程進行處理。線程開銷大。
• 偽異步IO：將請求連接放入線程池，一對多，但線程還是很寶貴的資源。
• NIO：一個請求一個線程，但客戶端發送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理。
• AIO：一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知服務器應用去啟動線程進行處理，
• BIO是面向流的，NIO是面向緩沖區的；BIO的各種流是阻塞的。而NIO是非阻塞的；BIO的Stream是單向的，而NIO的channel是雙向的。
• NIO的特點：事件驅動模型、單線程處理多任務、非阻塞I/O，I/O讀寫不再阻塞，而是返回0、基于block的傳輸比基于流的傳輸更高效、更高級的IO函數zero-copy、IO多路復用大大提高了Java網絡應用的可伸縮性和實用性。基于Reactor線程模型。
• 在Reactor模式中，事件分發器等待某個事件或者可應用或個操作的狀態發生，事件分發器就把這個事件傳給事先注冊的事件處理函數或者回調函數，由后者來做實際的讀寫操作。如在Reactor中實現讀：注冊讀就緒事件和相應的事件處理器、事件分發器等待事件、事件到來，激活分發器，分發器調用事件對應的處理器、事件處理器完成實際的讀操作，處理讀到的數據，注冊新的事件，然后返還控制權。

2.NIO的組成？

• Buffer：與Channel進行交互，數據是從Channel讀入緩沖區，從緩沖區寫入Channel中的
• flip方法 ： 反轉此緩沖區，將position給limit，然后將position置為0，其實就是切換讀寫模式
• clear方法 ：清除此緩沖區，將position置為0，把capacity的值給limit。
• rewind方法 ： 重繞此緩沖區，將position置為0
• DirectByteBuffer可減少一次系統空間到用戶空間的拷貝。但Buffer創建和銷毀的成本更高，不可控，通常會用內存池來提高性能。直接緩沖區主要分配給那些易受基礎系統的本機I/O 操作影響的大型、持久的緩沖區。如果數據量比較小的中小應用情況下，可以考慮使用heapBuffer，由JVM進行管理。
• Channel：表示 IO 源與目標打開的連接，是雙向的，但不能直接訪問數據，只能與Buffer 進行交互。通過源碼可知，FileChannel的read方法和write方法都導致數據復制了兩次！
• Selector可使一個單獨的線程管理多個Channel，open方法可創建Selector，register方法向多路復用器器注冊通道，可以監聽的事件類型：讀、寫、連接、accept。注冊事件后會產生一個SelectionKey：它表示SelectableChannel 和Selector 之間的注冊關系，wakeup方法：使尚未返回的第一個選擇操作立即返回，喚醒的原因是：注冊了新的channel或者事件；channel關閉，取消注冊；優先級更高的事件觸發（如定時器事件），希望及時處理。
• Selector在Linux的實現類是EPollSelectorImpl，委托給EPollArrayWrapper實現，其中三個native方法是對epoll的封裝，而EPollSelectorImpl. implRegister方法，通過調用epoll_ctl向epoll實例中注冊事件，還將注冊的文件描述符(fd)與SelectionKey的對應關系添加到fdToKey中，這個map維護了文件描述符與SelectionKey的映射。
• fdToKey有時會變得非常大，因為注冊到Selector上的Channel非常多（百萬連接）；過期或失效的Channel沒有及時關閉。fdToKey總是串行讀取的，而讀取是在select方法中進行的，該方法是非線程安全的。
• Pipe：兩個線程之間的單向數據連接，數據會被寫到sink通道，從source通道讀取
• NIO的服務端建立過程：Selector.open()：打開一個Selector；ServerSocketChannel.open()：創建服務端的Channel；bind()：綁定到某個端口上。并配置非阻塞模式；register()：注冊Channel和關注的事件到Selector上；select()輪詢拿到已經就緒的事件

3.Netty的特點？

• 一個高性能、異步事件驅動的NIO框架，它提供了對TCP、UDP和文件傳輸的支持
• 使用更高效的socket底層，對epoll空輪詢引起的cpu占用飆升在內部進行了處理，避免了直接使用NIO的陷阱，簡化了NIO的處理方式。
• 采用多種decoder/encoder 支持，對TCP粘包/分包進行自動化處理
• 可使用接受/處理線程池，提高連接效率，對重連、心跳檢測的簡單支持
• 可配置IO線程數、TCP參數， TCP接收和發送緩沖區使用直接內存代替堆內存，通過內存池的方式循環利用ByteBuf
• 通過引用計數器及時申請釋放不再引用的對象，降低了GC頻率
• 使用單線程串行化的方式，高效的Reactor線程模型
• 大量使用了volitale、使用了CAS和原子類、線程安全類的使用、讀寫鎖的使用

4.Netty的線程模型？

• Netty通過Reactor模型基于多路復用器接收并處理用戶請求，內部實現了兩個線程池，boss線程池和work線程池，其中boss線程池的線程負責處理請求的accept事件，當接收到accept事件的請求時，把對應的socket封裝到一個NioSocketChannel中，并交給work線程池，其中work線程池負責請求的read和write事件，由對應的Handler處理。
• 單線程模型：所有I/O操作都由一個線程完成，即多路復用、事件分發和處理都是在一個Reactor線程上完成的。既要接收客戶端的連接請求,向服務端發起連接，又要發送/讀取請求或應答/響應消息。一個NIO 線程同時處理成百上千的鏈路，性能上無法支撐，速度慢，若線程進入死循環，整個程序不可用，對于高負載、大并發的應用場景不合適。
• 多線程模型：有一個NIO 線程（Acceptor） 只負責監聽服務端，接收客戶端的TCP 連接請求；NIO 線程池負責網絡IO 的操作，即消息的讀取、解碼、編碼和發送；1 個NIO 線程可以同時處理N 條鏈路，但是1 個鏈路只對應1 個NIO 線程，這是為了防止發生并發操作問題。但在并發百萬客戶端連接或需要安全認證時，一個Acceptor 線程可能會存在性能不足問題。
• 主從多線程模型：Acceptor 線程用于綁定監聽端口，接收客戶端連接，將SocketChannel 從主線程池的Reactor 線程的多路復用器上移除，重新注冊到Sub 線程池的線程上，用于處理I/O 的讀寫等操作，從而保證mainReactor只負責接入認證、握手等操作；

5.TCP 粘包/拆包的原因及解決方法？

• TCP是以流的方式來處理數據，一個完整的包可能會被TCP拆分成多個包進行發送，也可能把小的封裝成一個大的數據包發送。
• TCP粘包/分包的原因：
• 應用程序寫入的字節大小大于套接字發送緩沖區的大小，會發生拆包現象，而應用程序寫入數據小于套接字緩沖區大小，網卡將應用多次寫入的數據發送到網絡上，這將會發生粘包現象；
• 進行MSS大小的TCP分段，當TCP報文長度-TCP頭部長度>MSS的時候將發生拆包
• 以太網幀的payload（凈荷）大于MTU（1500字節）進行ip分片。
• 解決方法
• 消息定長：FixedLengthFrameDecoder類
• 包尾增加特殊字符分割：行分隔符類：LineBasedFrameDecoder或自定義分隔符類 ：DelimiterBasedFrameDecoder
• 將消息分為消息頭和消息體：LengthFieldBasedFrameDecoder類。分為有頭部的拆包與粘包、長度字段在前且有頭部的拆包與粘包、多擴展頭部的拆包與粘包。

6.了解哪幾種序列化協議？

7.如何選擇序列化協議？

8.Netty的零拷貝實現？

9.Netty的高性能表現在哪些方面？

10.NIOEventLoopGroup源碼？

如果你想突破自己的天花板，那一定要比別人付出更多，這個過程是很辛苦的。如果你認準了一條路，堅持走下去，你一定會獲得很多收獲和你滿意的答案。

轉載于:https://juejin.im/post/5cd54a06e51d456e831f69fb

總結

以上是生活随笔為你收集整理的Netty框架整体架构及源码知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。