• ??作者簡介：大家好，我是愛敲代碼的小黃，獨角獸企業的Java開發工程師，Java領域新星創作者，
• ??個人公眾號：愛敲代碼的小黃
• ??系列專欄：Java設計模式、資料結構和演算法
• ??如果文章知識點有錯誤的地方，請指正！和大家一起學習，一起進步??
• ??如果感覺博主的文章還不錯的話，請??三連支持??一下博主哦
• ??博主正在努力完成2022計劃中：以夢為馬，揚帆起航，2022追夢人

@

• 全網一圖流死磕決議 Netty 原始碼
  • 一、Netty 服務端的啟動
    • 1. Java NIO 的啟動
    • 2. Netty 服務端的啟動
  • 二、Netty 服務端的讀寫
    • 1.注冊讀事件
    • 2.讀資料
    • 3.寫資料
    • 4.刷資料
  • 三、總結

全網一圖流死磕決議 Netty 原始碼

通過之前介紹的幾篇關于 Netty 的文章，相信大家多少對 Netty 有了一點了解，本篇文章主要從整個 Netty 的呼叫流程圖來做一個匯總

往期文章：

• 【Netty 從成神到升仙系列 五】Netty 的責任鏈真有這么神奇嗎？
• 【Netty 從成神到升仙系列 四】讓我們一起探索 Netty 中的零拷貝
• 【Netty 從成神到升仙系列 三】Netty 憑什么成為國內最流行的網路通信框架？
• 【Netty 從成神到升仙系列 二】你真的懂 NIOEventLoop 嘛？
• 【Netty 從成神到升仙系列 一】Netty 服務端的啟動原始碼剖析（一）

一、Netty 服務端的啟動

Netty 服務端的整個啟動流程，我做成了一個流程圖：

高清的可在公眾號 愛敲代碼的小黃 回復：Netty，即可獲取

這個我們之前講過，在 【Netty 從成神到升仙系列 一】Netty 服務端的啟動原始碼剖析（一），當時通過原始碼的角度剖析了下 Netty 的啟動流程，

由于當時對于 Netty 整體的把控不太好，有一些細節性的東西選擇性的忽略，導致最終整體的連貫性差強人意

后來，學完 Netty 之后，又對服務端的啟動做了一些細致化的分析

1. Java NIO 的啟動

我們學過 Netty 的都知道，Netty 無非在 Java NIO 的基礎上做了一定的優化，使得 I/O 網路的效率大大提高

但從整體來說，Netty 服務端的啟動和 Java NIO 的啟動基本一模一樣，主要集中在以下幾方面：

• 創建一個 selector 物件

  Selector selector = Selector.open();
  ServerSocketChannel ssc = ServerSocketChannel.open(); // 創建FD-1
  ssc.configureBlocking(false); // 非阻塞模式
  

• 建立 selector 與 channel 的聯系（注冊）

  SelectionKey sscKey = ssc.register(selector, SelectionKey.OP_ACCEPT, null);
  

• 注冊埠號

  ssc.bind(new InetSocketAddress(8080));
  

而我們 Netty 用了好多好多的代碼去描述了上述幾行代碼，

當我看完第一遍 Netty 服務端啟動流程，感覺這樣寫的好處在哪呢，完全沒有 GET 到，當我第二遍帶著疑惑去看并畫清流程圖之后，發現 Netty 的原始碼確實令人耳目一新

具體表現在哪些方面呢，我們可以繼續往下看

2. Netty 服務端的啟動

我們看到，最核心的當屬 Pipline，這里我們也不多介紹了，之前也都講過，

從整體來看，其實和我們寫的業務代碼也差不多，但博主感覺比較厲害的一點就是：對于一些我們不需要立即獲取結果的處理，全部封裝成 Task 交給執行緒處理，這樣會讓我們的系統執行緒的使用率提高并且性能提升，

在輪詢處理時，也會使用 ioRatio 控制 I/O 的比例，同時依靠計數器解決了 Epoll 空輪詢的BUG，

我們初始化時，分別有 BOSS 和 WORK 兩個執行緒組，我們的 BOSS 執行緒組主要用來接受客戶端的連接事件，而 WORK 執行緒組用來處理客戶端的讀事件，

二、Netty 服務端的讀寫

通過上述 Netty 服務端的啟動，我們向我們的 Selector 上注冊了 OP_ACCEPT 事件，當有客戶端連接到服務端時，就會觸發該事件，

1.注冊讀事件

通過上述的流程圖我們可以看到，通過 Channel 的不同來實作不同的 unsafe.read() 的實作

這里 channel 不同主要指的是：NioServerSocketChannel 和 NioSocketChannel 兩種

對于 NioServerSocketChannel 來說，負責接受當前客戶端的 連接請求，生成 NioSocketChannel 將當前的連接注冊到 Work 的執行緒組上（childGroup.register(child)）并向 Selector 上注冊 讀事件（接受客戶端）

2.讀資料

而對于 NioSocketChannel，主要負責處理客戶端的 讀請求

對于讀資料來說，主要通過 allocHandle.lastBytesRead(doReadBytes(byteBuf)) 進行讀取

這里說下讀取及擴容的邏輯：

• 服務端默認接受客戶端的 byteBuf 是 1024
• Netty 的 byteBuf 可以根據接受資料的大小進行動態的擴縮容（SIZE_TABLE），規律如下：
  • 擴容：當小于 512 時，一次性增加 64，當大于 512 時，一次性增加 16倍
  • 縮容：當小于 512 時，一次性減少 16，當大于 512 時，一次性減少 一倍
  • 當然，原始碼中擴縮容的前提不同：縮容需要連續兩次都小于，而擴容只需要大于一次就可以
  • byteBuf 擴容也是有范圍限制的：默認在64和65536之間
• 什么時候停止資料的讀取，主要由 allocHandle.continueReading() 控制
  • 當前的資料已被讀取完畢
  • 當前的資料被讀取16次，需要結束
  • 這里規定讀取次數的原因：控制次數，防止無限次回圈，浪費執行緒，

3.寫資料

上面在讀取資料時，會呼叫 pipeline.fireChannelRead(byteBuf)，這里會執行 Pipline 上的各個 Handler 的 channelRead方法，這里我們一般使用 writeAndFlush 和 write，我們分開來講，

首先，對于 write 的方法，主要由 incrementPendingOutboundBytes(long size, boolean invokeLater) 執行，這里會向 ChannelOutboundBuffer 寫入資訊并判斷當前寫入的資料是否超越水位線（默認 64 * 1024），

如果超越了我們的水位線，我們會給與 ChannelOutboundBuffer 一個標記，將 unwritable = 0(false) 修改為 unwritable = 1(true)，這樣在我們后續發送的程序中，可以根據此標記讓應用自己選擇是否發送，

這里的 ChannelOutboundBuffer 主要相當于一個容器，write 向里面寫，Flush 往內核發，

4.刷資料

這里的刷資料，指的是用戶空間的 Buffer 向內核空間的 Scoket 刷資料，類似：

我們的資料會發送到 Socket 緩沖區，由網卡發出，

我們來講一講 Netty 的 Flush 流程：

• 判斷當前通道是否關閉（防止當前的客戶端已經斷開連接）
• 刷資料
  • case 0：檔案資料，通過零拷貝刷，這里之前講過，參考：【Netty 從成神到升仙系列 四】讓我們一起探索 Netty 中的零拷貝
  • case 1：單個資料的寫入
  • default：批量資料的寫入：由于批量資料寫入，必然存在緩沖區滿的問題，當緩沖區滿的時候，Netty 會注冊一個 寫事件，當緩沖區有空閑時，觸發寫事件，交由其他執行緒處理，
• 如果寫了16次資料還沒有寫完的話，會新起一個 flush 任務，讓其余的 Work 執行緒執行該任務，這里不需要寫事件的原因：當前的快取區是空閑的，如果注冊了寫事件，會造成不斷的有寫事件觸發，

這里可能有小伙伴們疑惑，為什么一個寫事件就能避免批量資料寫入的問題，緩沖區滿與空閑代表什么？

當我們的服務端收到客戶端的請求時，我們會 write 和 flush，我們從整個流程看下：

對于服務端來說，我們的 flush 操作會將處理用戶態的 buffer 中的資料刷到內核態的 Scoket緩沖區 中

對于客戶端來說，會通過網卡接受服務端的資料并重繪到 Scoket緩沖區 中，通過用戶態的 buffer 讀取

如果我們當前的服務端發送的資料過大，客戶端接受的資料過少，就會導致服務端這邊的 Scoket緩沖區 阻塞

• 87380 ：tcp 接識訓沖區的默認值
• 16384 ： tcp 發送緩沖區的默認值

這個時候，我們只能等待 Scoket緩沖區 有空閑時，繼續向里面 flush，但這種無疑會把當前的執行緒阻塞住，違背 NIO 的架構初衷

所以，當批量的資料一次性寫入不成功時，我們會向 Selector 注冊一個寫事件，當 Scoket緩沖區 有空閑時，會觸發該事件，并交由其他的 work 執行緒去處理，這樣極大的發揮了 Netty 高效的網路通訊框架的作用，

三、總結

自此，Netty 的章節基本就結束了~

不得不說，學習 Netty 的程序還是挺痛苦的，有一些網路層面的東西，之前都沒有接觸過，只能慢慢的去補

還有一些學習中的疑惑，也需要大量的時間去消化，比如：

• Netty 為什么能成為最高效的網路 I/O 框架？
  • 當你剛學習時，你可能會聽說 NIO 使 Netty 變的有效起來
• NIO 是什么？為什么會出現 NIO？
  • 這個時候你會了解到，主要由于 C10K 的經典問題出現，導致了 NIO 的出現
  • NIO 實際上是 Linux 下 IO多路復用的機制，通過 select、poll、epoll三種方式來實作
• select、poll、epoll 是什么？
  • 了解到每個實作方式的不同以及慢慢的優化，最終采用的 epoll 作為當前 NIO 的實作
• 網路是怎么發送的？Socket 的本質又是什么？
• Linux 網路編程又是如何實作的？

其實，慢慢的思索，好像學習一個知識，會帶來一系列的蝴蝶效應，尤其是對下層知識的缺乏，導致自己上層知識的不穩定，

就像我一開始其實是分析的 kafka 的原始碼，到了通信那一節，看不懂了

于是去看了看 IO，繼而又去看 作業系統、計算機網路等

不過用了這么多時間，還算有成效，至少 Netty 可以懂了一點了

本期的內容就到這里，后續的話，可能會出一篇 select、poll、epoll 的文章，其次，后面應該會重新回到 kafka 的原始碼決議來

我是一名獨角獸企業的Java開發工程師，希望可以點個關注呀，有問題可以留言或者私信，我們下期再見！

本文由博客一文多發平臺 OpenWrite 發布！

標籤：Java

上一篇：SpringBoot(九) - Swagger

下一篇：快取 - 方法注解組件開發