摘要：如果什么事都沒得做，它也不會死循環，它會將線程休眠起來，直到下一個事件來了再繼續干活，這樣的一個線程稱之為線程。而請求處理邏輯既可以使用多帶帶的線程池進行處理，也可以跟放在讀寫線程一塊處理。

有了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你就可以定制編解碼協議，實現自己的特定協議的服務器。

上面是一個傳統處理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() // 寫消息
 }
 }
}

一個NIO線程+一個accept線程：

主從Reactor多線程：多個acceptor的NIO線程池用于接受客戶端的連接

Netty可以基于如上三種模型進行靈活的配置。

Netty是建立在NIO基礎之上，Netty在NIO之上又提供了更高層次的抽象。

在Netty里面，Accept連接可以使用多帶帶的線程池去處理，讀寫操作又是另外的線程池來處理。

Accept連接和讀寫操作也可以使用同一個線程池來進行處理。而請求處理邏輯既可以使用多帶帶的線程池進行處理，也可以跟放在讀寫線程一塊處理。線程池中的每一個線程都是NIO線程。用戶可以根據實際情況進行組裝，構造出滿足系統需求的高性能并發模型。

如果不用netty，使用原生JDK的話，有如下問題：

1、API復雜

2、對多線程很熟悉：因為NIO涉及到Reactor模式

3、高可用的話：需要出路斷連重連、半包讀寫、失敗緩存等問題

4、JDK NIO的bug

而Netty來說，他的api簡單、性能高而且社區活躍（dubbo、rocketmq等都使用了它）

現象

先看如下代碼，這個代碼是使用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));

是在發送數據的時候，傳統的實現方式是：

File.read(bytes)

Socket.send(bytes)

這種方式需要四次數據拷貝和四次上下文切換：

數據從磁盤讀取到內核的read buffer

數據從內核緩沖區拷貝到用戶緩沖區

數據從用戶緩沖區拷貝到內核的socket buffer

數據從內核的socket buffer拷貝到網卡接口（硬件）的緩沖區

明顯上面的第二步和第三步是沒有必要的，通過java的FileChannel.transferTo方法，可以避免上面兩次多余的拷貝（當然這需要底層操作系統支持）

調用transferTo,數據從文件由DMA引擎拷貝到內核read buffer

接著DMA從內核read buffer將數據拷貝到網卡接口buffer

上面的兩次操作都不需要CPU參與，所以就達到了零拷貝。

主要體現在三個方面：

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相關知識整理，如果有不同的見解，歡迎討論！