Netty | 第1章 Java NIO 網路程式設計《Netty In Action》

目錄

• 前言
• 1. Java 網路程式設計
  • 1.1 Javs NIO 基本介紹
  • 1.2 緩衝區 Buffer
  • 1.2 通道 Channel
  • 1.3 選擇器 Selector
  • 1.4 NIO 非阻塞網路程式設計原理分析
• 2. 執行緒模型概述
  • 2.1 傳統阻塞 IO 服務模型
  • 2.2 Reactor 模式
  • 2.3 單 Reactor 單執行緒模式
  • 2.4 單 Reactor 多執行緒模式
  • 2.5 主從 Reactor 多執行緒模式
  • 2.6 Netty 模型
• 最後

---

前言

參考資料：

• 《Netty In Action》；
• B站 《尚矽谷 Netty 視訊教程》；

本系列為 Netty 學習筆記，本篇介紹總結Java NIO 網路程式設計。Netty 作為一個非同步的、事件驅動的網路應用程式框架，也是基於NIO的客戶、伺服器端的程式設計框架。其對 Java NIO 底層 API 進行了封裝，因此有必要對 Java 網路程式設計做個大概瞭解。本篇將重點放在 NIO 網路程式設計模型上，對 BIO 及 AIO 僅做簡要說明；

---

1. Java 網路程式設計

• 最早期的 Java API（java.net）只支援由本地系統套接字型檔提供的阻塞函式，其弊端有：
  • 一個執行緒只能處理一條連線；
  • 在任何時候都可能有大量執行緒處於休眠狀態，可能造成資源浪費；
  • 需要為每個執行緒的呼叫棧分配記憶體；
  • 上下文切換帶來的開銷會很麻煩；
• 2002年，JDK 1.4 在 java.nio 包中引入非阻塞 IO（NIO）。使用事件通知 API 以確定在一組非阻塞套接字中有哪些已經就緒能夠進行 IO 相關的操作；
• 非阻塞 IO 的優勢有：
  • 使用較少執行緒便可處理許多連線，減少了記憶體管理和上下文切換帶來的開銷；
  • 沒有 IO 操作需要處理時，執行緒可以被用於其他任務；
• Java 支援3中網路程式設計模式 ：BIO(同步阻塞型)、NIO(同步非阻塞型)、AIO(非同步非阻塞型)；
  • BIO：適用於連線數目較小且固定的架構；
  • NIO：適用於連結數量多且連線比較短的架構；
  • AIO：適用於連線數目多且連線比較長的架構；
• BIO 以流的方式處理書局，NIO 以塊的方式處理書局，塊 IO 的效率比流 IO 高很多；

1.1 Javs NIO 基本介紹

• NIO 的三大核心部分部分：Channel(通道)、Buffer(緩衝區)、Selector(選擇器)；
  • 每個 Channel 都會對應一個 Buffer；
  • Selector 對應一個執行緒，一個執行緒對應多個 Channel；
  • 多個 Channel 可以註冊到一個 Selector；
  • 程式切換到哪個 Channel 由事件 Event 決定；
  • Selector 會根據不同的事件，在各個通道上切換；
  • Buffer 就是一個記憶體塊，底層是一個陣列；
  • 資料的讀取和寫入通過 Buffer，與 BIO 不同。BIO 要麼是輸入流，要麼是輸出流，不能雙向，而 NIO 的 Buffer 是雙向的；
  • Channel 也是雙向的，可以反映底層作業系統的情況；底層的作業系統通道就是雙向的；

• NIO 是面向緩衝區，或者面向塊程式設計的；
• NIO 可以做到用一個執行緒來處理多個操作；
• HTTP 2.0 使用了多路複用技術，做到同一個連線併發處理多個請求；

1.2 緩衝區 Buffer

• 緩衝區本質是一個可以讀寫的記憶體塊，可以理解成一個容器物件，該物件提供一組方法，可以更輕鬆地使用記憶體塊；

• 緩衝期內建了一些機制，能夠跟蹤和記錄緩衝區的狀態變化情況；

• Channel 提供從檔案、網路讀取資料的通道，但讀取或寫入的資料必須經由 Buffer；

• Buffer 有四個通用屬性：

  • capacity：容量，即可以容納的最大資料量；在快取區建立時被設定並且不能改變；
  • limit：表示緩衝區當前的終點，不能對緩衝區中超過Limit的部分進行讀寫（相當於哨兵）。而且Limit是可以修改的；
  • position：當前的讀/寫位置，下一個要被讀或寫的元素的索引，每次讀寫緩衝區資料時都會改變改值，為下次讀寫作準備；
  • mark：標記；

• Buffer 類的通用方法：

  public abstract class Buffer {
      //JDK1.4時，引入的api
      public final int capacity()//返回此緩衝區的容量
      public final int position()//返回此緩衝區的位置
      public final Buffer position (int newPositio)//設定此緩衝區的位置
      public final int limit()//返回此緩衝區的限制
      public final Buffer limit (int newLimit)//設定此緩衝區的限制
      public final Buffer mark()//在此緩衝區的位置設定標記
      public final Buffer reset()//將此緩衝區的位置重置為以前標記的位置
      public final Buffer clear()//清除此緩衝區, 即將各個標記恢復到初始狀態，但是資料並沒有真正擦除, 後面操作會覆蓋
      public final Buffer flip()//反轉此緩衝區
      public final Buffer rewind()//重繞此緩衝區
      public final int remaining()//返回當前位置與限制之間的元素數
      public final boolean hasRemaining()//告知在當前位置和限制之間是否有元素
      public abstract boolean isReadOnly();//告知此緩衝區是否為只讀緩衝區
  
      //JDK1.6時引入的api
      public abstract boolean hasArray();//告知此緩衝區是否具有可訪問的底層實現陣列
      public abstract Object array();//返回此緩衝區的底層實現陣列
      public abstract int arrayOffset();//返回此緩衝區的底層實現陣列中第一個緩衝區元素的偏移量
      public abstract boolean isDirect();//告知此緩衝區是否為直接緩衝區
  }
  

• Buffer 類及其子類：
  

1.2 通道 Channel

• BIO 中的 stream 是單向的，例如 FileInputStream 物件只能進行讀取資料的操作，而 NIO 中的通道(Channel)是雙向的，可以讀操作，也可以寫操作;
• Channel 在 NIO 中是一個介面 public interface Channel extends Closeable{}；
• 常 用 的 Channel 類 有 ： FileChannel 、 DatagramChannel 、 ServerSocketChannel 和 SocketChannel：
  
• NIO 還支援 通過多個 Buffer(即 Buffer 陣列) 完成讀寫操作，即 Scattering 和 Gathering；

1.3 選擇器 Selector

• Java 的 NIO，用非阻塞的 IO 方式。可以用一個執行緒，處理多個的客戶端連線，就會使用到 Selector(選擇器)；
• Selector 能夠檢測多個註冊的通道上是否有事件發生；
• 如果有事件發生，便獲取事件然後針對每個事件進行相應的處理。這樣就可以只用一個單執行緒去管理多個通道，也就是管理多個連線和請求（IO多路複用技術）；
• Netty 的 IO 執行緒 NioEventLoop 聚合了 Selector(選擇器，也叫多路複用器)，可以同時併發處理成百上千個客戶端連線；

1.4 NIO 非阻塞網路程式設計原理分析

• 當客戶端連線時，會通過 ServerSocketChannel 得到 SocketChannel；
• 將 socketChannel 註冊到 Selector 上（register 方法）；
• 註冊後返回一個 SelectionKey，會和該 Selector 關聯(集合)；
• Selector 進行監聽（select 方法），對於有事件發生的通道，將對應的 SelectionKey 加入到內部集合中並返回；
• 再通過 SelectionKey 反向獲取 SocketChannel （方法 channel）；
• 可以通過得到的 channel，完成業務處理；

2. 執行緒模型概述

• 目前存在的執行緒模型有：
  • 傳統阻塞 IO 服務模型；
  • Reactor 模式；根據 Reactor 的數量和處理資源池執行緒的數量不同，有3種典型的實現：
    • 單 Reactor 單執行緒；
    • 單 Reactor 多執行緒；
    • 主從 Reactor 多執行緒；
• Netty 主要基於主從 Reactor 多執行緒模型做了一定的改進，其中主從 Reactor 多執行緒模型有多個 Reactor；

2.1 傳統阻塞 IO 服務模型

• 特點：
  • 採用阻塞 IO 模式獲取輸入的資料；
  • 每個連線都需要獨立的執行緒完成資料的輸入，業務處理，資料返回；
• 問題：
  • 當併發數很大，就會建立大量的執行緒，佔用很大系統資源；
  • 連線建立後，如果當前執行緒暫時沒有資料可讀，該執行緒會阻塞在 read 操作，造成執行緒資源浪費；

• 黃色的框表示物件， 藍色的框表示執行緒，白色的框表示方法(API)；

2.2 Reactor 模式

• Reactor 模式又稱：反應器模式、分發者模式(Dispatcher)、通知者模式(Notifier)；
• 特點：
  • 基於 IO 複用模型：多個連線共用一個阻塞物件，應用程式只需要在一個阻塞物件等待，無需阻塞等待所有連線。當某個連線有新的資料可以處理時，作業系統通知應用程式，執行緒從阻塞狀態返回，開始進行業務處理；
  • 基於執行緒池複用執行緒資源：不必再為每個連線建立執行緒，將連線完成後的業務處理任務分配給執行緒進行處理；
• 說明：
  • 通過一個或多個輸入同時傳遞給服務處理器 ServiceHandler 的模式(基於事件驅動)；
  • 伺服器端程式處理傳入的多個請求，並將它們同步分派到相應的處理執行緒， 因此 Reactor 模式也叫 Dispatcher 模式；
  • Reactor 模式使用IO複用監聽事件，收到事件後，分發給某個執行緒(程式)，這點就是網路伺服器高併發處理關鍵；
• 核心組成：
  • Reactor：即：服務處理器 ServiceHandler：在一個單獨的執行緒中執行，負責監聽和分發事件，分發給適當的處理程式來對 IO 事件做出反應。 它就像公司的電話接線員，它接聽來自客戶的電話並將線路轉移到適當的聯絡人；
  • Handlers：即：事件處理器 EventHandler：處理程式執行 I/O 事件要完成的實際事件，類似於客戶想要與之交談的公司中的實際官員。Reactor 通過排程適當的處理程式來響應 I/O 事件，處理程式執行非阻塞操作；
• 優點：
  • 響應快，不必為單個同步時間所阻塞，雖然 Reactor 本身依然是同步的；
  • 可以最大程度的避免複雜的多執行緒及同步問題，並且避免了多執行緒/程式的切換開銷；
  • 擴充套件性好，可以方便的通過增加 Reactor 例項個數來充分利用 CPU 資源；
  • 複用性好，Reactor 模型本身與具體事件處理邏輯無關，具有很高的複用性；

• 黃色的框表示物件， 藍色的框表示執行緒，白色的框表示方法(API)；

2.3 單 Reactor 單執行緒模式

• 方案說明：
  • Select 是前面 IO 複用模型介紹的標準網路程式設計 API，可以實現應用程式通過一個阻塞物件監聽多路連線請求；
  • Reactor 物件通過 select 監控客戶端請求事件。收到事件後，通過 dispatch 進行分發；
  • 如果建立連線請求，則 Acceptor 通過 accept 處理連線請求，然後建立一個 Handler 物件處理完成連線後的各種事件；
  • 如果不是連線請求，則由 Reactor 分發呼叫連線對應的 handler 來處理；
  • Handler 會完成：read → 業務處理 → send 的完整業務流程；
• 優點：
  • 模型簡單，沒有多執行緒、程式通訊、競爭的問題，全部都在一個執行緒中完成；
• 缺點：
  • 效能問題，只有一個執行緒，無法完全發揮多核 CPU 的效能。Handler 在處理某個連線上的業務時，整個程式無法處理其他連線事件，很容易導致效能瓶頸；
  • 可靠性問題，執行緒意外終止，或者進入死迴圈，會導致整個系統通訊模組不可用，不能接收和處理外部訊息，造成節點故障；
• 應用場景：
  • 客戶端的數量有限，業務處理非常快速。如：Redis 在業務處理的時間複雜度 O(1) 的情況；

• 黃色的框表示物件， 藍色的框表示執行緒，白色的框表示方法(API)；

2.4 單 Reactor 多執行緒模式

• 方案說明：
  • Reactor 物件通過 select 監控客戶端請求事件，收到事件後，通過 dispatch 進行分發；
  • 如果建立連線請求, 則 Acceptor 通過 accept 處理連線請求，然後建立一個 Handler 物件處理完成連線後的各種事件；
  • 如果不是連線請求，則由 Reactor 通過 dispatch 分發呼叫連線對應的 Handler 來處理；
  • Handler 只負責響應事件，不做具體的業務處理，通過 read 讀取資料後，會分發給後面的 Worker 執行緒池的某個執行緒處理業務；
  • Worker 執行緒池會分配獨立執行緒完成真正的業務，並將結果返回給 Handler；
  • Handler 收到響應後，通過 send 將結果返回給 Client（圖中未標出）；
• 優點：
  • 可以充分的利用多核 cpu 的處理能力；
• 缺點：
  • 多執行緒資料共享和訪問比較複雜；
  • Reactor 處理所有的事件的監聽和響應，在單執行緒執行、高併發場景容易出現效能瓶頸；
    
  • 黃色的框表示物件， 藍色的框表示執行緒，白色的框表示方法(API)；

2.5 主從 Reactor 多執行緒模式

• 方案說明：
  • Reactor 主執行緒 MainReactor 物件通過 select 監聽連線事件。收到事件後，通過 Acceptor 處理連線事件；
  • 當 Acceptor 處理連線事件後，MainReactor 將連線分配給 SubReactor（多個）；
  • SubReactor 將連線加入到連線佇列進行監聽，並建立 Handler 進行各種事件處理；
  • 當有新事件發生時， Subreactor 就會呼叫對應的 Handler 處理；
  • Handler 先 read 讀取資料，然後分發給後面的 Worker 執行緒池處理；
  • Worker 執行緒池分配獨立的 Worker 執行緒進行業務處理，並返回結果；
  • Handler 收到響應的結果後，再通過 send 將結果返回給 Client；
  • Reactor 主執行緒可以對應多個 Reactor 子執行緒，即 MainRecator 可以關聯多個 SubReactor；
• 優點：
  • 父執行緒與子執行緒的資料互動簡單職責明確，父執行緒只需要接收新連線，子執行緒完成後續的業務處理；
  • 父執行緒與子執行緒的資料互動簡單，Reactor 主執行緒只需要把新連線傳給子執行緒，子執行緒無需返回資料；
• 缺點：
  • 程式設計複雜度較高；
• 應用場景：
  • 這種模型在許多專案中廣泛使用，包括 Nginx 主從 Reactor 多程式模型，Memcached 主從多執行緒，Netty 主從多執行緒模型的支援；

• 黃色的框表示物件， 藍色的框表示執行緒，白色的框表示方法(API)；

2.6 Netty 模型

• Netty 主要基於主從 Reactors 多執行緒模型做了一定的改進，其中主從 Reactor 多執行緒模型有多個 Reactor；
• 方案說明：
  • Netty 抽象出兩組執行緒池： BossGroup 專門負責接收客戶端的連線、WorkerGroup 專門負責網路的讀寫；
  • BossGroup 和 WorkerGroup 型別都是 NioEventLoopGroup 。NioEventLoopGroup 相當於一個事件迴圈組，這個組中含有多個事件迴圈，每一個事件迴圈是 NioEventLoop；
  • NioEventLoop 表示一個不斷迴圈的執行處理任務的執行緒， 每個 NioEventLoop 都有一個 Selector，用於監聽繫結在其上的 socket 的網路通訊；
  • 每個 Boss NioEventLoop 迴圈執行的步驟有 3 步：
    • 輪詢 accept 事件；
    • 處理 accept 事件，與 Client 建立連線，生成 NioScocketChannel，並將其註冊到某個 Worker NIOEventLoop 上 的 Selector；
    • 處理任務佇列的其他任務 ， 即 runAllTasks；
  • 每個 Worker NIOEventLoop 迴圈執行的步驟有 3 步：
    • 輪詢 read、write 事件；
    • 在對應 NioScocketChannel上進行 處理 IO 事件， 即 read、write 事件；
    • 處理任務佇列的其他任務 ， 即 runAllTasks；
  • 每個 WorkerNIOEventLoop 處理業務時，會使用 pipeline(管道)，pipeline 中包含了 channel，即通過 pipeline 可以獲取到對應通道，管道中維護了很多的處理器；

---

最後

新人制作，如有錯誤，歡迎指出，感激不盡！ 歡迎關注公眾號，會分享一些更日常的東西！ 如需轉載，請標註出處！