文章目錄

• 一、 NIO 原生 API 弊端
• 二、 Netty 簡介
• 三、 Netty 架構
• 四、 Netty 版本
• 五、 Netty 線程模型
• 六、 阻塞 IO 線程模型
• 七、 反應器 ( Reactor ) 模式引入

一、 NIO 原生 API 弊端

---

NIO 原生 API 的弊端 :

① NIO 組件復雜 : 使用原生 NIO 開發服務器端與客戶端 , 需要涉及到 服務器套接字通道 ( ServerSocketChannel ) , 套接字通道 ( SocketChannel ) , 選擇器 ( Selector ) , 緩沖區 ( ByteBuffer ) 等組件 , 這些組件的原理 , API 都要熟悉 , 才能進行 NIO 的開發與調試 , 之后還需要針對應用進行調試 , 優化 ;

② NIO 開發基礎 : NIO 門檻略高 , 需要開發者掌握 多線程 , 網絡編程 , 才能開發并且優化 NIO 網絡通信的應用程序 ;

③ 原生 API 開發網絡通信模塊的基本的傳輸處理 : 網絡傳輸不光是實現服務器端和客戶端的數據傳輸功能 , 還要處理各種異常情況 , 如 連接斷開重連機制 , 網絡堵塞處理 , 異常處理 , 沾包處理 , 半包拼接處理 , 緩存機制 等方面的問題 , 這是所有成熟的網絡應用程序都要具有的功能 , 否則只能說是入門級的 Demo ;

④ NIO BUG : NIO 本身存在一些 BUG , 如 Epoll , 導致 選擇器 ( Selector ) 空輪詢 , 在 JDK 1.7 中還沒有解決 ;

Netty 在 NIO 的基礎上 , 封裝了 Java 原生的 NIO API , 解決了上述問題 ;

二、 Netty 簡介

---

Netty 簡介 : Netty 是一個網絡應用框架 ;

① Netty 特點 :

• 異步 : 可以開發 阻塞 / 非阻塞 網絡通信功能 ;
• 基于事件驅動 : 底層封裝了可擴展的事件模型 ;

② Netty 使用場景 : 快速開發 高性能 的服務器端與客戶端應用程序 ;

③ Netty 原理 : Netty 框架 對 Java 的原生 NIO API 進行了二次封裝 , 適用于各種類型的 IO 通信 ( 阻塞 / 非阻塞 ) , 兼容各種協議 ( TCP / UDP / HTTP ) ;

④ Netty 安全性 : Netty 支持 SSL / TSL / StartTSL 等安全協議 ;

⑤ Netty 社區 : Netty 社區很活躍 , 截止到當前 , Netty 一直在持續維護 , 半個月前剛發布了新的版本 ;

2 . Netty 相關網站 :

① Netty 官網 : https://netty.io/

② Netty 下載頁面 : https://netty.io/downloads.html

三、 Netty 架構

---

Netty 架構 :

① 底層核心 : 零拷貝字節緩沖區 , 通用的交互通信 API , 擴展的事件模型 ;

② Netty 支持的協議和功能 : HTTP 協議 , WebSocket 協議 ( 開發瀏覽器長連接程序 ) , zlib / gzip 數據壓縮功能 , SSL 安全連接功能開發 , StartTLS 協議 , Google Protobuf 編碼解碼 , 大文件傳輸 , RTSP 協議 ;

③ 支持的傳輸服務 : TCP / UDP 協議傳輸 , HTTP 隧道傳輸 ;

四、 Netty 版本

---

Netty 版本 :

① Netty 3.x : 版本太老 , 不推薦使用 ;

② Netty 4.x : 目前正在使用的版本 ( 必須使用這個版本 ) , 目前最新的是 netty-4.1.50 版本 ( 2020-05-13 ) ;

③ Netty 5.x : 由于出現重大 BUG , 已經廢棄 , 不能使用 ;

五、 Netty 線程模型

---

1 . 現有的線程模型 : 主要分為 阻塞 IO 模型 , 反應器模式 , 兩個大的類型 ;

① 阻塞 IO 模型 : 傳統的 BIO 模型 , 即阻塞 IO 模型 ;

② 反應器 ( Reactor ) 模式 : 反應器 ( Reactor ) 模式根據 反應器 和 處理線程 數量進行分類 , 又可以分為以下三類 :

• 單 反應器 ( Reactor ) 單線程 模式
• 單 反應器 ( Reactor ) 多線程 模式
• 主從 反應器 ( Reactor ) 多線程 模式

上述 反相器 ( Reactor ) 模型分類都有相應的模型支撐 ;

2 . Netty 線程模型 : Netty 的線程模型是在上面的 反應器 ( Reactor ) 模式分類下的 主從反應器 ( Reactor ) 多線程模型 的基礎上 , 進行改進而來的 ;

Reactor 對應的中文翻譯 : 反應器 / 分發者 / 通知者 ;

六、 阻塞 IO 線程模型

---

1 . 阻塞 IO 線程模型 :

① 場景說明 : 這里以服務器端為例 , 前提是連接已經建立 , 當前處于數據傳輸階段 ;

② 主要用途 : 使用阻塞 IO 模型 , 獲取客戶端輸入數據 ;

③ 阻塞獲取數據 : 服務器端開始處于阻塞狀態 , 接收到客戶端數據后 , 解除阻塞 , 處理客戶端上傳的數據 ;

④ 線程模型 : 基于阻塞獲取數據 , 如果沒有數據到來 , 則需要一直處于阻塞狀態 , 因此 每個連接都需要一個獨立的線程處理對應客戶端連接的數據交互 ;

2 . 阻塞 IO 模型弊端 :

① 客戶端 連接 線程 對應關系 : 該模式下 , 每個客戶端都要維持一個連接 , 每個連接都需要占用一個線程資源處理數據交互 ;

② 資源消耗 : 如果客戶端數量非常大 , 如十萬百萬級別 , 服務器大并發處理壓力非常大 , 創建很多線程 , 消耗的系統資源巨大 ;

③ 資源浪費 : 如果服務器端與客戶端沒有數據交互 , 那么服務器端會阻塞的 read() 方法上 , 此時線程處于阻塞狀態 , 但還占用著系統的資源 , 造成了資源的浪費 ;

阻塞 IO 模型 , 資源消耗大 , 浪費也大 ;

下圖是 BIO 模型的示意圖 , 在該模型中每個客戶端都要占用服務器端的一個線程 ;

七、 反應器 ( Reactor ) 模式引入

---

1 . 針對 BIO 模型的 資源浪費 的解決方案 : 線程 IO 復用模型 ;

① BIO 模型中的資源浪費 : 服務器端的線程 大部分時間都處于阻塞狀態 , 沒有數據交互時 , 還占用著線程資源 ;

② 單個線程為多個連接服務 : 多個連接共用一個線程 , 在這個線程中監聽多個連接是否有數據寫入 , 不用每個連接都各自占用一個線程阻塞監聽 ;

③ 線程解除阻塞機制 : 多個連接中如果有某個連接收到數據 , 該線程就會 解除監聽阻塞 , 開始為有數據寫入的連接服務 ;

該模型中 , 一個線程為多個連接服務 , 類似于 NIO 模型的機制 , 該機制就是之前講過的 在單個線程中使用 單個選擇器 ( Selector ) 阻塞監聽多個客戶端對應的多個套接字通道 ( SocketChannel ) ;

( 該 反應器模式 與 NIO 模型類似 , 但不是 NIO 模型 )

2 . 針對 BIO 模型的 資源消耗 的解決方案 : 使用線程池機制 , 實現對線程資源的復用 ;

① BIO 模型中的資源消耗 : 每個客戶端都要建立一個對應的連接 , 每個連接都要占用一個線程 , 這樣需要創建很多線程 ;

② 線程池機制復用線程 : 每個連接不再分配單獨的線程進行處理 , 使用線程池機制分配線程資源 ;

③ 業務與線程的對應關系 : 每個業務邏輯都可能分配給多個線程中的一個 ( 不能同時分配多個 ) , 每個線程可以承擔多個連接的業務 ( 不能同時承擔多個 ) , 其對應關系是多對多的 ;

( 同一時刻 , 一個線程只能對應一個連接的業務 , 一個連接的業務邏輯也只能交給一個線程處理 )

總結

以上是生活随笔為你收集整理的【Netty】Netty 简介 ( 原生 NIO 弊端 | Netty 框架 | Netty 版本 | 线程模型 | 线程 阻塞 IO 模型 | Reactor 模式引入 )的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。