前言
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 是面向緩沖區，或者面向塊編程的；
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，完成業務處理；

NIO 非阻塞網路編程原理分析

2. 執行緒模型概述

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

2.1 傳統阻塞 IO 服務模型

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

傳統阻塞 IO 服務模型

黃色的框表示物件，藍色的框表示執行緒，白色的框表示方法(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 模型本身與具體事件處理邏輯無關，具有很高的復用性；

Reactor 模式

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

2.3 單 Reactor 單執行緒模式

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

單 Reactor 單執行緒模式

黃色的框表示物件，藍色的框表示執行緒，白色的框表示方法(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 主從多執行緒模型的支持；

主從 Reactor 多執行緒模式

黃色的框表示物件，藍色的框表示執行緒，白色的框表示方法(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 可以獲取到對應通道，管道中維護了很多的處理器；