1. 回應式編程
1.1. 使用基于事件的范式處理異步資料流
1.2. 和異步編程提供了相同的性能優勢
1.3. 能夠擴展程式（特別是擴展I/O）以處理很多連接和資料源
2. 非阻塞I/O
2.1. 有效擴展服務器的基礎
2.2. 允許服務器用相對較少的執行緒處理相對較多的連接
-
2.2.1. 傳統的服務器利用這一點來處理基本的客戶端連接
-
2.2.2. 新的服務器可以將非阻塞特性擴展到其他應用程式
3. 優化服務器執行緒池
3.1. 選擇器執行緒
- 3.1.1. 在I/O可用時通知系統呼叫的執行緒
3.2. 選擇器通知有客戶端I/O待處理之后，另一個包含作業執行緒的執行緒池會處理實際的請求和回應
3.3. 要足夠多的作業執行緒來處理服務器所能處理的并發請求數（而非并發連接數）
3.4. 像所有受限于CPU的情況一樣，執行緒的數量沒有必要比運行服務器的機器或容器的虛擬CPU數量多，因為永遠沒有辦法運行那么多的執行緒
3.5. 將長請求推遲到另一個執行緒池中，這為主執行緒池提供了更強大的請求處理能力
3.6. 異步REST服務器
-
3.6.1. 使用異步回應有3個原因
-
3.6.1.1. 為了在業務邏輯中引入更多的并行性
-
3.6.1.2. 為了限制活躍執行緒的數量
-
3.6.1.3. 為了適當地對服務器限流
-
-
3.6.2. 添加了@Suspended注解的AsyncResponse正在等待邏輯完成，一旦完成，它就會繼續將回應發回給用戶
-
3.6.3. 在排隊等待回應之前，看看異步執行緒池的狀態，如果系統太忙，就拒絕請求
-
3.6.4. 如果執行緒數量等于池大小，回應會被立即取消
- 3.6.4.1. 呼叫者會立即收到錯誤提示“HTTP 503服務不可用”，表示此時不能處理該請求
-
3.6.5. 立即回傳該錯誤能減少過載服務器的負載，這最侄訓使整體性能大幅提高
- 3.6.5.1. 這是REST處理過載服務器的首選方式
4. 異步出站呼叫
4.1. HTTP客戶端
-
4.1.1. 處理發向服務器的HTTP請求類
-
4.1.2. 可以通過在多個執行緒之間分配作業來提高性能，從而增加并發量
-
4.1.3. java.net.HttpURLConnection類
- 4.1.3.1. Java 8
-
4.1.4. java.net.HttpsURLConnection
- 4.1.4.1. Java 8
-
4.1.5. java.net.http. HttpClient類
-
4.1.5.1. 也處理HTTPS
-
4.1.5.2. Java 11
-
-
4.1.6. org.apache.http.client.HttpClient
- 4.1.6.1. Apache軟體基金會
-
4.1.7. org.asynchttpclient.AsyncHttpClient
- 4.1.7.1. Netty專案
-
4.1.8. org.eclipse.jetty.client.HttpClient
- 4.1.8.1. Eclipse基金
4.2. JAX-RS
-
4.2.1. JAX-RS連接器提供了一個Client物件用于REST呼叫
-
4.2.2. HTTP客戶端可以正確地池化連接并使用keepalive來保持連接開放
4.3. -Dhttp.maxConnections=N
-
4.3.1. 改變池的大小
-
4.3.2. 默認值是5
-
4.3.3. 適用于HTTPS連接
-
4.3.4. 不能起到限流的作用
4.4. HttpClient類
-
4.4.1. JDK 11
-
4.4.2. 默認的池大小是無限制的
-
4.4.3. -Djdk.httpclient.connectionPoolSize=N
-
4.4.3.1. 不能起到限流的作用
-
4.4.3.2. 請求的連接超過了配置的數量，它們會在需要的時候被創建，在完成任務后被銷毀
-
4.5. 與使用傳統I/O構建的客戶端相比，使用NIO構建的異步HTTP客戶端需要的執行緒更少
4.6. 但REST服務器仍然需要相當多的執行緒來處理異步請求
5. 異步資料庫呼叫
5.1. 使用最廣泛的是Spring專案的Spring Data R2DBC
- 5.1.1. 對于關系資料庫的非阻塞訪問來說，這是最好的選擇
5.2. 針對回應式NoSQL資料庫的Spring專案可以用于真正的異步訪問
6. 格式
6.1. Apache Avro
6.2. Google的Protocol Buffers
6.3. XML
6.4. JSON
7. JSON處理
7.1. 解碼（unmarshaling）
- 7.1.1. 輸出的是一個Java物件
7.2. 決議（parsing）
- 7.2.1. 資料在讀取時被處理，這個程序就叫作決議
7.3. 給定一系列JSON字串，程式必須將這些字串轉換為適合Java處理的資料
7.4. 編碼（marshaling）
- 7.4.1. 從其他資料生成JSON字串的程序
7.5. 通用技術
-
7.5.1. 拉決議器（pull parser）
- 7.5.1.1. 輸入的資料與決議器相關聯，程式從決議器請求（或拉取）一系列標記（token）
-
7.5.2. 檔案模型（document model）
- 7.5.2.1. 輸入的資料被轉換為一個檔案風格的物件，應用程式可以在尋找資料片段時遍歷這個物件
-
7.5.3. 物件表示（object representation）
-
7.5.3.1. 通過使用一組反映資料結構的預定義類，將輸入的資料轉換成一個或多個Java物件
-
7.5.3.2. POJO（plain old Java object）
-
7.6. JSON資料表示形式
-
7.6.1. 簡單JSON物件
-
7.6.1.1. 通用介面進行操作，如JsonObject和JsonArray
-
7.6.1.2. 不需要具體表示資料的類
-
7.6.1.3. 生成簡單JSON物件比生成自定義Java類要快得多
-
-
7.6.2. JSON物件表示形式
-
7.6.2.1. 從編程的角度來看，這些Java類更容易使用
-
7.6.2.2. 使用可以產生POJO的JSON-B（JSON Binding），將JSON資料系結到一個完整的Java類
-
7.7. Jackson
- 7.7.1. Jackson決議器通常是最快的決議器，應該優先選擇它，而不是選擇默認的實作
7.8. 所有的JSON決議器都是拉決議器
-
7.8.1. 從流中按需檢索資料
-
7.8.2. 實際的決議器不能被重復使用，它們也不是執行緒安全的，因此，決議器通常是按需創建的
7.9. 處理JSON有兩種方式：創建POJO物件和直接決議
-
7.9.1. 直接決議提供了過濾的能力和通用的性能提升機會
-
7.9.2. 當物件很大時，創建JSON物件往往會導致GC問題
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/548316.html
標籤：Java