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源碼？
如果你想突破自己的天花板，那一定要比別人付出更多，這個過程是很辛苦的。如果你認準了一條路，堅持走下去，你一定會獲得很多收穫和你滿意的答案。
最後，希望以上的分享能給大家帶來收穫。更多面試題領取方式加入Java貓的架構學習基地：810589193免費獲取！！！