Java核心知識點整理大全-筆記_希斯奎的博客-CSDN博客

Java核心知識點整理大全2-筆記_希斯奎的博客-CSDN博客

Java核心知識點整理大全3-筆記_希斯奎的博客-CSDN博客

Java核心知識點整理大全4-筆記-CSDN博客

Java核心知識點整理大全5-筆記-CSDN博客

Java核心知識點整理大全6-筆記-CSDN博客

Java核心知識點整理大全7-筆記-CSDN博客

Java核心知識點整理大全8-筆記-CSDN博客

Java核心知識點整理大全9-筆記-CSDN博客

Java核心知識點整理大全10-筆記-CSDN博客

Java核心知識點整理大全11-筆記-CSDN博客

Java核心知識點整理大全12-筆記-CSDN博客

Java核心知識點整理大全13-筆記-CSDN博客

Java核心知識點整理大全14-筆記-CSDN博客

往期快速傳送門👆：

---

目錄

7.1.7. API 管理

8. Netty 與 RPC

8.1.1. Netty 原理

8.1.2. Netty 高性能

8.1.2.1. 多路復(fù)用通訊方式

8.1.2.1. 異步通訊 NIO

8.1.2.2. 零拷貝（DIRECT BUFFERS 使用堆外直接內(nèi)存）

8.1.2.3. 內(nèi)存池（基于內(nèi)存池的緩沖區(qū)重用機制）

8.1.2.4. 高效的 Reactor 線程模型

Reactor 多線程模型

主從 Reactor 多線程模型

8.1.2.5. 無鎖設(shè)計、線程綁定

8.1.2.6. 高性能的序列化框架

小包封大包，防止網(wǎng)絡(luò)阻塞

軟中斷 Hash 值和 CPU 綁定

8.1.3. Netty RPC 實現(xiàn)

8.1.3.1. 概念

8.1.3.2. 關(guān)鍵技術(shù)

8.1.3.3. 核心流程

8.1.3.1. 消息編解碼

序列化

8.1.3.1. 通訊過程

核心問題(線程暫停、消息亂序)

通訊流程

存放回調(diào)對象 callback 到全局 ConcurrentHashMap

synchronized 獲取回調(diào)對象 callback 的鎖并自旋 wait

監(jiān)聽消息的線程收到消息，找到 callback 上的鎖并喚醒

8.1.4. RMI 實現(xiàn)方式

---

7.1.7. API 管理

SwaggerAPI 管理工具。

8. Netty 與 RPC

8.1.1. Netty 原理

Netty 是一個高性能、異步事件驅(qū)動的 NIO 框架，基于 JAVA NIO 提供的 API 實現(xiàn)。它提供了對 TCP、UDP 和文件傳輸?shù)闹С?#xff0c;作為一個異步 NIO 框架，Netty 的所有 IO 操作都是異步非阻塞 的，通過 Future-Listener 機制，用戶可以方便的主動獲取或者通過通知機制獲得 IO 操作結(jié)果。

8.1.2. Netty 高性能

在 IO 編程過程中，當(dāng)需要同時處理多個客戶端接入請求時，可以利用多線程或者 IO 多路復(fù)用技術(shù) 進行處理。IO 多路復(fù)用技術(shù)通過把多個 IO 的阻塞復(fù)用到同一個 select 的阻塞上，從而使得系統(tǒng)在 單線程的情況下可以同時處理多個客戶端請求。與傳統(tǒng)的多線程/多進程模型比，I/O 多路復(fù)用的 最大優(yōu)勢是系統(tǒng)開銷小，系統(tǒng)不需要創(chuàng)建新的額外進程或者線程，也不需要維護這些進程和線程 的運行，降低了系統(tǒng)的維護工作量，節(jié)省了系統(tǒng)資源。 與 Socket 類和 ServerSocket 類相對應(yīng)，NIO 也提供了 SocketChannel 和 ServerSocketChannel 兩種不同的套接字通道實現(xiàn)。

8.1.2.1. 多路復(fù)用通訊方式

Netty 架構(gòu)按照 Reactor 模式設(shè)計和實現(xiàn)，它的服務(wù)端通信序列圖如下

客戶端通信序列圖如下：

Netty 的 IO 線程 NioEventLoop 由于聚合了多路復(fù)用器 Selector，可以同時并發(fā)處理成百上千個 客戶端 Channel，由于讀寫操作都是非阻塞的，這就可以充分提升 IO 線程的運行效率，避免由于 頻繁 IO 阻塞導(dǎo)致的線程掛起。

8.1.2.1. 異步通訊 NIO

由于 Netty 采用了異步通信模式，一個 IO 線程可以并發(fā)處理 N 個客戶端連接和讀寫操作，這從根 本上解決了傳統(tǒng)同步阻塞 IO 一連接一線程模型，架構(gòu)的性能、彈性伸縮能力和可靠性都得到了極 大的提升。

8.1.2.2. 零拷貝（DIRECT BUFFERS 使用堆外直接內(nèi)存）

1. Netty 的接收和發(fā)送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接內(nèi)存進行 Socket 讀寫， 不需要進行字節(jié)緩沖區(qū)的二次拷貝。如果使用傳統(tǒng)的堆內(nèi)存（HEAP BUFFERS）進行 Socket 讀寫， JVM 會將堆內(nèi)存 Buffer 拷貝一份到直接內(nèi)存中，然后才寫入 Socket 中。相比于堆外直接內(nèi)存， 消息在發(fā)送過程中多了一次緩沖區(qū)的內(nèi)存拷貝。

2. Netty 提供了組合 Buffer 對象，可以聚合多個 ByteBuffer 對象，用戶可以像操作一個 Buffer 那樣 方便的對組合 Buffer 進行操作，避免了傳統(tǒng)通過內(nèi)存拷貝的方式將幾個小 Buffer 合并成一個大的 Buffer。

3. Netty的文件傳輸采用了transferTo方法，它可以直接將文件緩沖區(qū)的數(shù)據(jù)發(fā)送到目標(biāo)Channel， 避免了傳統(tǒng)通過循環(huán) write 方式導(dǎo)致的內(nèi)存拷貝問題

8.1.2.3. 內(nèi)存池（基于內(nèi)存池的緩沖區(qū)重用機制）

隨著 JVM 虛擬機和 JIT 即時編譯技術(shù)的發(fā)展，對象的分配和回收是個非常輕量級的工作。但是對于緩 沖區(qū) Buffer，情況卻稍有不同，特別是對于堆外直接內(nèi)存的分配和回收，是一件耗時的操作。為了盡 量重用緩沖區(qū)，Netty 提供了基于內(nèi)存池的緩沖區(qū)重用機制。

8.1.2.4. 高效的 Reactor 線程模型

常用的 Reactor 線程模型有三種，Reactor 單線程模型, Reactor 多線程模型, 主從 Reactor 多線程模 型。 Reactor 單線程模型 Reactor 單線程模型，指的是所有的 IO 操作都在同一個 NIO 線程上面完成，NIO 線程的職責(zé)如下：

1) 作為 NIO 服務(wù)端，接收客戶端的 TCP 連接；

2) 作為 NIO 客戶端，向服務(wù)端發(fā)起 TCP 連接；

3) 讀取通信對端的請求或者應(yīng)答消息；

4) 向通信對端發(fā)送消息請求或者應(yīng)答消息

由于 Reactor 模式使用的是異步非阻塞 IO，所有的 IO 操作都不會導(dǎo)致阻塞，理論上一個線程可以獨 立處理所有 IO 相關(guān)的操作。從架構(gòu)層面看，一個 NIO 線程確實可以完成其承擔(dān)的職責(zé)。例如，通過 Acceptor 接收客戶端的 TCP 連接請求消息，鏈路建立成功之后，通過 Dispatch 將對應(yīng)的 ByteBuffer 派發(fā)到指定的 Handler 上進行消息解碼。用戶 Handler 可以通過 NIO 線程將消息發(fā)送給客戶端。

Reactor 多線程模型

Rector 多線程模型與單線程模型最大的區(qū)別就是有一組 NIO 線程處理 IO 操作。 有專門一個 NIO 線程-Acceptor 線程用于監(jiān)聽服務(wù)端，接收客戶端的 TCP 連接請求； 網(wǎng)絡(luò) IO 操作-讀、寫 等由一個 NIO 線程池負(fù)責(zé)，線程池可以采用標(biāo)準(zhǔn)的 JDK 線程池實現(xiàn)，它包含一個任務(wù)隊列和 N 個可用的線程，由這些 NIO 線程負(fù)責(zé)消息的讀取、解碼、編碼和發(fā)送；

主從 Reactor 多線程模型

服務(wù)端用于接收客戶端連接的不再是個 1 個單獨的 NIO 線程，而是一個獨立的 NIO 線程池。 Acceptor 接收到客戶端 TCP 連接請求處理完成后（可能包含接入認(rèn)證等），將新創(chuàng)建的 SocketChannel 注冊到 IO 線程池（sub reactor 線程池）的某個 IO 線程上，由它負(fù)責(zé) SocketChannel 的讀寫和編解碼工作。Acceptor 線程池僅僅只用于客戶端的登陸、握手和安全 認(rèn)證，一旦鏈路建立成功，就將鏈路注冊到后端 subReactor 線程池的 IO 線程上，由 IO 線程負(fù) 責(zé)后續(xù)的IO 操作。

8.1.2.5. 無鎖設(shè)計、線程綁定

Netty 采用了串行無鎖化設(shè)計，在 IO 線程內(nèi)部進行串行操作，避免多線程競爭導(dǎo)致的性能下降。 表面上看，串行化設(shè)計似乎 CPU 利用率不高，并發(fā)程度不夠。但是，通過調(diào)整 NIO 線程池的線程 參數(shù)，可以同時啟動多個串行化的線程并行運行，這種局部無鎖化的串行線程設(shè)計相比一個隊列多個工作線程模型性能更優(yōu)。

Netty 的 NioEventLoop 讀取到消息之后，直接調(diào)用 ChannelPipeline 的 fireChannelRead(Object msg)，只要用戶不主動切換線程，一直會由 NioEventLoop 調(diào)用 到用戶的 Handler，期間不進行線程切換，這種串行化處理方式避免了多線程操作導(dǎo)致的鎖 的競爭，從性能角度看是最優(yōu)的。

8.1.2.6. 高性能的序列化框架

Netty 默認(rèn)提供了對 Google Protobuf 的支持，通過擴展 Netty 的編解碼接口，用戶可以實現(xiàn)其它的 高性能序列化框架，例如 Thrift 的壓縮二進制編解碼框架。 1. SO_RCVBUF 和 SO_SNDBUF：通常建議值為 128K 或者 256K。

小包封大包，防止網(wǎng)絡(luò)阻塞

2. SO_TCPNODELAY：NAGLE 算法通過將緩沖區(qū)內(nèi)的小封包自動相連，組成較大的封包，阻止大量 小封包的發(fā)送阻塞網(wǎng)絡(luò)，從而提高網(wǎng)絡(luò)應(yīng)用效率。但是對于時延敏感的應(yīng)用場景需要關(guān)閉該優(yōu)化算 法。

軟中斷 Hash 值和 CPU 綁定

3. 軟中斷：開啟 RPS 后可以實現(xiàn)軟中斷，提升網(wǎng)絡(luò)吞吐量。RPS 根據(jù)數(shù)據(jù)包的源地址，目的地址以 及目的和源端口，計算出一個 hash 值，然后根據(jù)這個 hash 值來選擇軟中斷運行的 cpu，從上層 來看，也就是說將每個連接和 cpu 綁定，并通過這個 hash 值，來均衡軟中斷在多個 cpu 上，提升 網(wǎng)絡(luò)并行處理性能。

8.1.3. Netty RPC 實現(xiàn)

8.1.3.1. 概念

RPC，即 Remote Procedure Call（遠(yuǎn)程過程調(diào)用），調(diào)用遠(yuǎn)程計算機上的服務(wù)，就像調(diào)用本地服務(wù)一 樣。RPC 可以很好的解耦系統(tǒng)，如 WebService 就是一種基于 Http 協(xié)議的 RPC。這個 RPC 整體框架 如下：

---

8.1.3.2. 關(guān)鍵技術(shù)

1. 服務(wù)發(fā)布與訂閱：服務(wù)端使用 Zookeeper 注冊服務(wù)地址，客戶端從 Zookeeper 獲取可用的服務(wù) 地址。

2. 通信：使用 Netty 作為通信框架。

3. Spring：使用 Spring 配置服務(wù)，加載 Bean，掃描注解。

4. 動態(tài)代理：客戶端使用代理模式透明化服務(wù)調(diào)用。

5. 消息編解碼：使用 Protostuff 序列化和反序列化消息。

8.1.3.3. 核心流程

1. 服務(wù)消費方（client）調(diào)用以本地調(diào)用方式調(diào)用服務(wù)；

2. client stub 接收到調(diào)用后負(fù)責(zé)將方法、參數(shù)等組裝成能夠進行網(wǎng)絡(luò)傳輸?shù)南Ⅲw；

3. client stub 找到服務(wù)地址，并將消息發(fā)送到服務(wù)端；

4. server stub 收到消息后進行解碼；

5. server stub 根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)；

6. 本地服務(wù)執(zhí)行并將結(jié)果返回給 server stub；

7. server stub 將返回結(jié)果打包成消息并發(fā)送至消費方；

8. client stub 接收到消息，并進行解碼；

9. 服務(wù)消費方得到最終結(jié)果。

RPC 的目標(biāo)就是要 2~8 這些步驟都封裝起來，讓用戶對這些細(xì)節(jié)透明。JAVA 一般使用動態(tài)代 理方式實現(xiàn)遠(yuǎn)程調(diào)用。

---

8.1.3.1. 消息編解碼

息數(shù)據(jù)結(jié)構(gòu)（接口名稱+方法名+參數(shù)類型和參數(shù)值+超時時間+ requestID）

客戶端的請求消息結(jié)構(gòu)一般需要包括以下內(nèi)容：

1. 接口名稱：在我們的例子里接口名是“HelloWorldService”，如果不傳，服務(wù)端就不知道調(diào)用哪 個接口了；

2. 方法名：一個接口內(nèi)可能有很多方法，如果不傳方法名服務(wù)端也就不知道調(diào)用哪個方法；

3. 參數(shù)類型和參數(shù)值：參數(shù)類型有很多，比如有 bool、int、long、double、string、map、list， 甚至如 struct（class）；以及相應(yīng)的參數(shù)值；

4. 超時時間：

5. requestID，標(biāo)識唯一請求 id，在下面一節(jié)會詳細(xì)描述 requestID 的用處。

6. 服務(wù)端返回的消息 ： 一般包括以下內(nèi)容。返回值+狀態(tài) code+requestID

序列化

目前互聯(lián)網(wǎng)公司廣泛使用 Protobuf、Thrift、Avro 等成熟的序列化解決方案來搭建 RPC 框架，這 些都是久經(jīng)考驗的解決方案。

8.1.3.1. 通訊過程

核心問題(線程暫停、消息亂序)

如果使用 netty 的話，一般會用 channel.writeAndFlush()方法來發(fā)送消息二進制串，這個方 法調(diào)用后對于整個遠(yuǎn)程調(diào)用(從發(fā)出請求到接收到結(jié)果)來說是一個異步的，即對于當(dāng)前線程來說， 將請求發(fā)送出來后，線程就可以往后執(zhí)行了，至于服務(wù)端的結(jié)果，是服務(wù)端處理完成后，再以消息 的形式發(fā)送給客戶端的。于是這里出現(xiàn)以下兩個問題：

1. 怎么讓當(dāng)前線程“暫?！?#xff0c;等結(jié)果回來后，再向后執(zhí)行？

2. 如果有多個線程同時進行遠(yuǎn)程方法調(diào)用，這時建立在 client server 之間的 socket 連接上 會有很多雙方發(fā)送的消息傳遞，前后順序也可能是隨機的，server 處理完結(jié)果后，將結(jié) 果消息發(fā)送給 client，client 收到很多消息，怎么知道哪個消息結(jié)果是原先哪個線程調(diào)用 的？如下圖所示，線程 A 和線程 B 同時向 client socket 發(fā)送請求 requestA 和 requestB， socket 先后將 requestB 和 requestA 發(fā)送至 server，而 server 可能將 responseB 先返 回，盡管 requestB 請求到達(dá)時間更晚。我們需要一種機制保證 responseA 丟給 ThreadA，responseB 丟給 ThreadB。

通訊流程

requestID 生成-AtomicLong

1. client 線程每次通過 socket 調(diào)用一次遠(yuǎn)程接口前，生成一個唯一的 ID，即 requestID （requestID 必需保證在一個 Socket 連接里面是唯一的），一般常常使用 AtomicLong 從 0 開始累計數(shù)字生成唯一 ID；

存放回調(diào)對象 callback 到全局 ConcurrentHashMap

2. 將 處 理 結(jié) 果 的 回 調(diào) 對 象 callback ， 存 放 到 全 局 ConcurrentHashMap 里 面 put(requestID, callback)；

synchronized 獲取回調(diào)對象 callback 的鎖并自旋 wait

3. 當(dāng)線程調(diào)用 channel.writeAndFlush()發(fā)送消息后，緊接著執(zhí)行 callback 的 get()方法試 圖獲取遠(yuǎn)程返回的結(jié)果。在 get()內(nèi)部，則使用 synchronized 獲取回調(diào)對象 callback 的 鎖，再先檢測是否已經(jīng)獲取到結(jié)果，如果沒有，然后調(diào)用 callback 的 wait()方法，釋放 callback 上的鎖，讓當(dāng)前線程處于等待狀態(tài)。

監(jiān)聽消息的線程收到消息，找到 callback 上的鎖并喚醒

4. 服務(wù)端接收到請求并處理后，將 response 結(jié)果（此結(jié)果中包含了前面的 requestID）發(fā) 送給客戶端，客戶端 socket 連接上專門監(jiān)聽消息的線程收到消息，分析結(jié)果，取到 requestID ， 再 從 前 面 的 ConcurrentHashMap 里 面 get(requestID) ， 從 而 找 到 callback 對象，再用 synchronized 獲取 callback 上的鎖，將方法調(diào)用結(jié)果設(shè)置到 callback 對象里，再調(diào)用 callback.notifyAll()喚醒前面處于等待狀態(tài)的線程。

 public Object get() {synchronized (this) { // 旋鎖while (true) { // 是否有結(jié)果了If （!isDone）{wait(); //沒結(jié)果釋放鎖，讓當(dāng)前線程處于等待狀態(tài)}else{//獲取數(shù)據(jù)并處理}}}}
private void setDone(Response res) {this.res = res;isDone = true;synchronized (this) { //獲取鎖，因為前面 wait()已經(jīng)釋放了 callback 的鎖了  notifyAll(); // 喚醒處于等待的線程}}

---

8.1.4. RMI 實現(xiàn)方式

Java 遠(yuǎn)程方法調(diào)用，即 Java RMI（Java Remote Method Invocation）是 Java 編程語言里，一種用 于實現(xiàn)遠(yuǎn)程過程調(diào)用的應(yīng)用程序編程接口。它使客戶機上運行的程序可以調(diào)用遠(yuǎn)程服務(wù)器上的對象。遠(yuǎn) 程方法調(diào)用特性使 Java 編程人員能夠在網(wǎng)絡(luò)環(huán)境中分布操作。RMI 全部的宗旨就是盡可能簡化遠(yuǎn)程接 口對象的使用。

---