Netty是一個高性能、異步事件驅(qū)動的NIO框架，它提供了對TCP、UDP和文件傳輸?shù)闹С?。作為當前最流行的NIO框架，Netty在互聯(lián)網(wǎng)領域、大數(shù)據(jù)分布式計算領域、游戲行業(yè)、通信行業(yè)等獲得了廣泛的應用，一些業(yè)界著名的開源組件也基于Netty的NIO框架構建。
Netty 利用 Java 高級網(wǎng)絡的能力，隱藏其背后的復雜性而提供一個易于使用的 API 構建一個客戶端/服務端，其具有高并發(fā)、傳輸快、封裝好等特點。
高并發(fā)
Netty是一款基于NIO（Nonblocking I/O，非阻塞IO）開發(fā)的網(wǎng)絡通信框架，對比于BIO（Blocking I/O，阻塞IO），他的并發(fā)性能得到了很大提高 。
傳輸快
Netty的傳輸快其實也是依賴了NIO的一個特性——零拷貝。
封裝好
Netty封裝了NIO操作的很多細節(jié)，提供易于使用的API，還有心跳、重連機制、拆包粘包方案等特性，使開發(fā)者能能夠快速高效的構建一個穩(wěn)健的高并發(fā)應用。
image
Netty項目致力于提供一個異步的、事件驅(qū)動的網(wǎng)絡應用框架和工具，用于快速開發(fā)可維護的、高性能的、高擴展性的服務器和客戶端之間的協(xié)議。換句話說，Netty式一個NIO客戶端服務器框架，能夠快速、輕松地開發(fā)網(wǎng)絡應用例如服務器和客戶端間的協(xié)議。它簡化了網(wǎng)絡編程如TCP/IP socket服務器。
JBOSSes Netty的設計吸取了大量的協(xié)議如FTP、SMTP、HTTP和各種二進制、基于文本的繼承協(xié)議等協(xié)議的設計經(jīng)驗，成功地找到了一種方法實現(xiàn)易于開發(fā)、性能、穩(wěn)定、靈活的協(xié)議開發(fā)。
特征：
Netty為用戶提供了很多創(chuàng)新和更好的網(wǎng)絡開發(fā)體驗。
1）設計Design
為各種傳輸類型（塊和非塊socket）提供了統(tǒng)一的API；
建立在靈活和可擴展的事件模型；
高度可定制的線程模式——單線程，一個或多個線程池（如SEDA）；
可信的五連接數(shù)據(jù)報socket支持。
2）易于使用
良好文檔化的Javadoc、用戶向?qū)Ш屠樱?/p>
結構并不臃腫；
無其它的依賴，只需JDK1.5或以上。
3）性能
高吞吐量、低延遲時間；
很小的資源消耗；
最小化不必要的內(nèi)存復制。
4）健壯性
不會因為快速連接、慢速連接或超載連接引起OutOfMemoryError錯誤；
高速網(wǎng)絡下不會引起NIO程序的讀寫異常。
5）安全
完全支持SSL/TLS和StartTLS；
在Java Applet環(huán)境下運行正常。
6）社區(qū)
至少每兩周一個版本發(fā)布。
項目主頁：?http://www.jboss.org/netty/
文檔地址：?http://www.jboss.org/netty/documentation.html
下載地址：?http://www.jboss.org/netty/downloads.html
Socket通信（IO/NIO/AIO）編程，對于通信模型已經(jīng)有了一個基本的認識。我們學習的僅僅是一個模型，如果想把這些真正的用于實際工作中，那么還需要不斷的完善、擴展和優(yōu)化。比如經(jīng)典的TCP讀包寫包問題，或者是數(shù)據(jù)接收的大小，實際的通信處理與應答的處理邏輯等等一些細節(jié)問題需要認真的去思考，而這些都需要大量的時間和經(jīng)歷，以及豐富的經(jīng)驗。所以想學好Socket通信不是件容易事，那么接下來就來學習一下新的技術Netty，為什么會選擇Netty？因為它簡單！使用Netty不必編寫復雜的邏輯代碼去實現(xiàn)通信，再也不需要去考慮性能問題，不需要考慮編碼問題，半包讀寫等問題。強大的Netty已經(jīng)幫我們實現(xiàn)好了，我們只需要使用即可。
Netty是最流行的NIO框架，它的健壯性、功能、性能、可定制性和可擴展性在同類框架都是首屈一指的。它已經(jīng)得到成百上千的商業(yè)/商用項目驗證，如Hadoop的RPC框架Avro、RocketMQ以及主流的分布式通信框架Dubbox等等。
image
并發(fā)系統(tǒng)可以采用多種并發(fā)編程模型來實現(xiàn)。并發(fā)模型指定了系統(tǒng)中的線程如何通過協(xié)作來完成分配給它們的作業(yè)。不同的并發(fā)模型采用不同的方式拆分作業(yè)，同時線程間的協(xié)作和交互方式也不相同。
對于網(wǎng)絡請求一般可以分為兩個處理階段，一是接收請求任務，二是處理網(wǎng)絡請求。根據(jù)不同階段處理方式分為以下幾種線程模型：
串行化處理模型
這個模型中用一個線程來處理網(wǎng)絡請求連接和任務處理，當worker接受到一個任務之后，就立刻進行處理，也就是說任務接受和任務處理是在同一個worker線程中進行的，沒有進行區(qū)分。這樣做存在一個很大的問題是，必須要等待某個task處理完成之后，才能接受處理下一個task。
而通常情況下，任務的處理過程會比任務的接受流程慢得多。例如在處理任務的時候，我們可能會需要訪問遠程數(shù)據(jù)庫，這屬于一種網(wǎng)絡IO。通常情況下IO操作是比較耗時的，這直接影響了下一個任務的接受，而且通常在IO操作的時候,CPU是比較空閑的，白白浪費了資源。
因此可以把接收任務和處理任務兩個階段分開處理，一個線程接收任務，放入任務隊列，另外的線程異步處理任務隊列中的任務。
并行化處理模型
由于任務處理一般比較緩慢，會導致任務隊列中任務積壓長時間得不到處理，這時可以使用多線程來處理。這里使用的是一個公共的任務隊列，多線程環(huán)境中不免要通過加鎖來保證線程安全，我們常用的線程池就是這種模式?？梢酝ㄟ^為每個線程維護一個任務隊列來改進這種模型。
Reactor線程模型
reactor線程模型關注的是：任務接受之后，對處理過程繼續(xù)進行切分，劃分為多個不同的步驟，每個步驟用不同的線程來處理，也就是原本由一個線程處理的任務現(xiàn)在由多個線程來處理，每個線程在處理完自己的步驟之后，還需要將任務轉(zhuǎn)發(fā)到下階段線程繼續(xù)進行處理。
其中mainReacotor,subReactor,Thread Pool是三個線程池。mainReactor負責處理客戶端的連接請求，并將accept的連接注冊到subReactor的其中一個線程上；subReactor負責處理客戶端通道上的數(shù)據(jù)讀寫；Thread Pool是具體的業(yè)務邏輯線程池，處理具體業(yè)務。
Netty具體線程模型
如何理解NioEventLoop和NioEventLoopGroup
1）NioEventLoop實際上就是工作線程，可以直接理解為一個線程。NioEventLoopGroup是一個線程池，線程池中的線程就是NioEventLoop。
2）實際上bossGroup中有多個NioEventLoop線程，每個NioEventLoop綁定一個端口，也就是說，如果程序只需要監(jiān)聽1個端口的話，bossGroup里面只需要有一個NioEventLoop線程就行了。
每個NioEventLoop都綁定了一個Selector，所以在Netty的線程模型中，是由多個Selecotr在監(jiān)聽IO就緒事件。而Channel注冊到Selector。
一個Channel綁定一個NioEventLoop，相當于一個連接綁定一個線程，這個連接所有的ChannelHandler都是在一個線程中執(zhí)行的，避免了多線程干擾。更重要的是ChannelPipline鏈表必須嚴格按照順序執(zhí)行的。單線程的設計能夠保證ChannelHandler的順序執(zhí)行。
一個NioEventLoop的selector可以被多個Channel注冊，也就是說多個Channel共享一個EventLoop。EventLoop的Selecctor對這些Channel進行檢查。
在監(jiān)聽一個端口的情況下，一個NioEventLoop通過一個NioServerSocketChannel監(jiān)聽端口，處理TCP連接。后端多個工作線程NioEventLoop處理IO事件。每個Channel綁定一個NioEventLoop線程，1個NioEventLoop線程關聯(lián)一個selector來為多個注冊到它的Channel監(jiān)聽IO就緒事件。NioEventLoop是單線程執(zhí)行，保證Channel的pipline在單線程中執(zhí)行，保證了ChannelHandler的執(zhí)行順序。
小編準備了關于netty的面試題分享給大家，由于文章篇幅原因以下只分享10道netty的面試題。后五道題未設置答案，需要獲取答案和更多Java架構資料、面試題（含答案）和面試心得以及視頻資料的可以加入Java貓的架構學習基地：810589193獲??！
1.BIO、NIO和AIO的區(qū)別？
BIO：一個連接一個線程，客戶端有連接請求時服務器端就需要啟動一個線程進行處理。線程開銷大。
偽異步IO：將請求連接放入線程池，一對多，但線程還是很寶貴的資源。
NIO：一個請求一個線程，但客戶端發(fā)送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理。
AIO：一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知服務器應用去啟動線程進行處理，
BIO是面向流的，NIO是面向緩沖區(qū)的；BIO的各種流是阻塞的。而NIO是非阻塞的；BIO的Stream是單向的，而NIO的channel是雙向的。
NIO的特點：事件驅(qū)動模型、單線程處理多任務、非阻塞I/O，I/O讀寫不再阻塞，而是返回0、基于block的傳輸比基于流的傳輸更高效、更高級的IO函數(shù)zero-copy、IO多路復用大大提高了Java網(wǎng)絡應用的可伸縮性和實用性?；赗eactor線程模型。
在Reactor模式中，事件分發(fā)器等待某個事件或者可應用或個操作的狀態(tài)發(fā)生，事件分發(fā)器就把這個事件傳給事先注冊的事件處理函數(shù)或者回調(diào)函數(shù)，由后者來做實際的讀寫操作。如在Reactor中實現(xiàn)讀：注冊讀就緒事件和相應的事件處理器、事件分發(fā)器等待事件、事件到來，激活分發(fā)器，分發(fā)器調(diào)用事件對應的處理器、事件處理器完成實際的讀操作，處理讀到的數(shù)據(jù)，注冊新的事件，然后返還控制權。
2.NIO的組成？
Buffer：與Channel進行交互，數(shù)據(jù)是從Channel讀入緩沖區(qū)，從緩沖區(qū)寫入Channel中的
flip方法 ： 反轉(zhuǎn)此緩沖區(qū)，將position給limit，然后將position置為0，其實就是切換讀寫模式
clear方法 ：清除此緩沖區(qū)，將position置為0，把capacity的值給limit。
rewind方法 ： 重繞此緩沖區(qū)，將position置為0
DirectByteBuffer可減少一次系統(tǒng)空間到用戶空間的拷貝。但Buffer創(chuàng)建和銷毀的成本更高，不可控，通常會用內(nèi)存池來提高性能。直接緩沖區(qū)主要分配給那些易受基礎系統(tǒng)的本機I/O 操作影響的大型、持久的緩沖區(qū)。如果數(shù)據(jù)量比較小的中小應用情況下，可以考慮使用heapBuffer，由JVM進行管理。
Channel：表示 IO 源與目標打開的連接，是雙向的，但不能直接訪問數(shù)據(jù)，只能與Buffer 進行交互。通過源碼可知，F(xiàn)ileChannel的read方法和write方法都導致數(shù)據(jù)復制了兩次！
Selector可使一個單獨的線程管理多個Channel，open方法可創(chuàng)建Selector，register方法向多路復用器器注冊通道，可以監(jiān)聽的事件類型：讀、寫、連接、accept。注冊事件后會產(chǎn)生一個SelectionKey：它表示SelectableChannel 和Selector 之間的注冊關系，wakeup方法：使尚未返回的第一個選擇操作立即返回，喚醒的原因是：注冊了新的channel或者事件；channel關閉，取消注冊；優(yōu)先級更高的事件觸發(fā)（如定時器事件），希望及時處理。
Selector在Linux的實現(xiàn)類是EPollSelectorImpl，委托給EPollArrayWrapper實現(xiàn)，其中三個native方法是對epoll的封裝，而EPollSelectorImpl. implRegister方法，通過調(diào)用epoll_ctl向epoll實例中注冊事件，還將注冊的文件描述符(fd)與SelectionKey的對應關系添加到fdToKey中，這個map維護了文件描述符與SelectionKey的映射。
fdToKey有時會變得非常大，因為注冊到Selector上的Channel非常多（百萬連接）；過期或失效的Channel沒有及時關閉。fdToKey總是串行讀取的，而讀取是在select方法中進行的，該方法是非線程安全的。
Pipe：兩個線程之間的單向數(shù)據(jù)連接，數(shù)據(jù)會被寫到sink通道，從source通道讀取
NIO的服務端建立過程：Selector.open()：打開一個Selector；ServerSocketChannel.open()：創(chuàng)建服務端的Channel；bind()：綁定到某個端口上。并配置非阻塞模式；register()：注冊Channel和關注的事件到Selector上；select()輪詢拿到已經(jīng)就緒的事件
3.Netty的特點？
一個高性能、異步事件驅(qū)動的NIO框架，它提供了對TCP、UDP和文件傳輸?shù)闹С?/p>
使用更高效的socket底層，對epoll空輪詢引起的cpu占用飆升在內(nèi)部進行了處理，避免了直接使用NIO的陷阱，簡化了NIO的處理方式。
采用多種decoder/encoder 支持，對TCP粘包/分包進行自動化處理
可使用接受/處理線程池，提高連接效率，對重連、心跳檢測的簡單支持
可配置IO線程數(shù)、TCP參數(shù)， TCP接收和發(fā)送緩沖區(qū)使用直接內(nèi)存代替堆內(nèi)存，通過內(nèi)存池的方式循環(huán)利用ByteBuf
通過引用計數(shù)器及時申請釋放不再引用的對象，降低了GC頻率
使用單線程串行化的方式，高效的Reactor線程模型
大量使用了volitale、使用了CAS和原子類、線程安全類的使用、讀寫鎖的使用
4.Netty的線程模型？
Netty通過Reactor模型基于多路復用器接收并處理用戶請求，內(nèi)部實現(xiàn)了兩個線程池，boss線程池和work線程池，其中boss線程池的線程負責處理請求的accept事件，當接收到accept事件的請求時，把對應的socket封裝到一個NioSocketChannel中，并交給work線程池，其中work線程池負責請求的read和write事件，由對應的Handler處理。
單線程模型：所有I/O操作都由一個線程完成，即多路復用、事件分發(fā)和處理都是在一個Reactor線程上完成的。既要接收客戶端的連接請求,向服務端發(fā)起連接，又要發(fā)送/讀取請求或應答/響應消息。一個NIO 線程同時處理成百上千的鏈路，性能上無法支撐，速度慢，若線程進入死循環(huán)，整個程序不可用，對于高負載、大并發(fā)的應用場景不合適。
多線程模型：有一個NIO 線程（Acceptor） 只負責監(jiān)聽服務端，接收客戶端的TCP 連接請求；NIO 線程池負責網(wǎng)絡IO 的操作，即消息的讀取、解碼、編碼和發(fā)送；1 個NIO 線程可以同時處理N 條鏈路，但是1 個鏈路只對應1 個NIO 線程，這是為了防止發(fā)生并發(fā)操作問題。但在并發(fā)百萬客戶端連接或需要安全認證時，一個Acceptor 線程可能會存在性能不足問題。
主從多線程模型：Acceptor 線程用于綁定監(jiān)聽端口，接收客戶端連接，將SocketChannel 從主線程池的Reactor 線程的多路復用器上移除，重新注冊到Sub 線程池的線程上，用于處理I/O 的讀寫等操作，從而保證mainReactor只負責接入認證、握手等操作；
5.TCP 粘包/拆包的原因及解決方法？
TCP是以流的方式來處理數(shù)據(jù)，一個完整的包可能會被TCP拆分成多個包進行發(fā)送，也可能把小的封裝成一個大的數(shù)據(jù)包發(fā)送。
TCP粘包/分包的原因：
應用程序?qū)懭氲淖止?jié)大小大于套接字發(fā)送緩沖區(qū)的大小，會發(fā)生拆包現(xiàn)象，而應用程序?qū)懭霐?shù)據(jù)小于套接字緩沖區(qū)大小，網(wǎng)卡將應用多次寫入的數(shù)據(jù)發(fā)送到網(wǎng)絡上，這將會發(fā)生粘包現(xiàn)象；
進行MSS大小的TCP分段，當TCP報文長度-TCP頭部長度>MSS的時候?qū)l(fā)生拆包
以太網(wǎng)幀的payload（凈荷）大于MTU（1500字節(jié)）進行ip分片。
解決方法
消息定長：FixedLengthFrameDecoder類
包尾增加特殊字符分割：行分隔符類：LineBasedFrameDecoder或自定義分隔符類 ：DelimiterBasedFrameDecoder
將消息分為消息頭和消息體：LengthFieldBasedFrameDecoder類。分為有頭部的拆包與粘包、長度字段在前且有頭部的拆包與粘包、多擴展頭部的拆包與粘包。
6.了解哪幾種序列化協(xié)議？
7.如何選擇序列化協(xié)議？
8.Netty的零拷貝實現(xiàn)？
9.Netty的高性能表現(xiàn)在哪些方面？
10.NIOEventLoopGroup源碼？
如果你想突破自己的天花板，那一定要比別人付出更多，這個過程是很辛苦的。如果你認準了一條路，堅持走下去，你一定會獲得很多收獲和你滿意的答案。
最后，希望以上的分享能給大家?guī)硎斋@。更多面試題領取方式加入Java貓的架構學習基地：810589193免費獲?。。?！
