1. 簡介

JSF 業務線程池使用 JDK 的線程池技術，缺省情況下采用 Cached 模式（核心線程數 20，最大線程數 200）。此外，還提供了 Fixed 固定線程大小的模式，兩種模式均可設置請求隊列大小。

本文旨在通過一個簡化場景（“單服務應用”）下的負載測試，為 “JSF 業務線程池大小配置” 提供基準測試結果，并形成一些普遍適用的結論。

本文的目標讀者包括需要合理配置 JSF 線程大小的壓測工程師、開發部署運維工程師以及架構師。

本文不涉及 JSF 服務端的其他配置項，也不針對 “復合服務應用” 的合理配置進行探討。你可以利用本文提供的結論，作為設計壓測用例或評估業務線程池大小的基本方法的參考，以便在實踐中合理配置 JSF 業務線程池大小。需要注意的是，JSF 業務線程池大小的合理配置應該基于高保真的負載測試結果。

“單服務應用” 指應用僅包含一個提供接口，且接口中僅有一個方法。 “復合服務應用” 則指應用包含多個提供接口或一個接口中含有多個方法。

2. 測試用例說明

本次基準測試選取了 USF3.0 權限系統，將其定制化為一個單一的服務提供者，僅對該提供者的一個方法進行了測試，因此可以看作是一個 “單服務應用”。

測試中將 CPU 作為基準測試的核心資源，并考慮到 JVM 垃圾收集器的影響，采用了簡單的測試數據以保證服務每次調用的一致性，并確保 YGC 具有規律性（即固定調用量會導致一次 30+ms 的 YGC），無 FGC 的影響。

測試用例的設計中，所有依賴的服務資源都無限制，以確保測試過程中服務的可用率達到 100%。我們的關鍵性能指標是 TP99，即服務響應時長的 99% 必須小于 10ms。

為了測試不同線程池模式下的性能表現，我們使用了 JSF 線程池的 Cached 和 Fixed 兩種模式，并針對每種模式進行了多組測試，以得出在滿足 TP99<10ms 的前提下，系統最大的負載情況。

測試應用：USF3.0 權限系統 (定制化處理) 測試服務：com.jd.susf.service.api.SusfPermissionService#findUserInfo，根據用戶信息從 Redis 中查詢一條數據返回的服務。

硬件配置：單臺 4C 8G 測試方法：在 Forcebot 系統采用了階梯發壓的方式對 JSF 業務線程池在 Cached 和 Fixed 模式下進行了系統負載測試 擬定 SLA 要求：服務響應時長的 TP99<10ms

注：我們對 USF3.0 權限系統進行了定制，調整了服務提供方的配置數據，僅保留了 com.jd.susf.service.api.SusfPermissionService。

3. 測試結果及分析

3.1.cached 線程池的系統負載

圖：JSF 默認線程池 (cached, threads=200) 在不同并發用戶數 (1-200) 下的系統負載圖

小結：默認的 JSF 線程池配置存在很大的風險。系統最大可支持 24 個并發，超過 24 個并發 SLA 就無法滿足。

3.2 fixed 線程池 (隊列) 的系統負載

圖：JSF 固定線程池 (fixed + 隊列) 在不同并發用戶數 (1-50) 下的系統負載圖

表：JSF 固定業務線程池 (fixed + 隊列) 在滿足 TP99<10ms 的系統最大負載（最大并發用戶數）

小結： ① 在 fixed 線程模式下，CPU 的利用率存在使用上限。

② 隊列的使用可以有效增加系統對并發量的支持，同時也會帶來吞吐量的提升。然而，由于任務在隊列中等待，服務的響應時間會出現 “水漲船高” 的現象，存在一定風險。

3.3 fixed 線程池的系統負載

圖：JSF 固定線程池 (fixed) 模式下，系統最大并發用戶數時的系統負載

小結：綜合固定線程池 (fixed) 的性能表現，需要設置一個合理的線程數大小來平衡 CPU 資源的充分利用和滿足 SLA 的需求，線程數過小會導致 CPU 資源浪費，線程數過大則無法滿足 SLA

4. 結論

根據測試結果和數據分析，我們得出以下結論：

JSF 線程池的默認配置在并發量高的場景下存在風險：所有線上生產環境中的 JSF 服務所在的服務器，很少有能夠在 200 個線程的情況下還能夠滿足 SLA 的。最大 200 個線程的線程池配置，將服務器置于 “并發量高的場景下被壓垮” 的風險中。線程池大小的合理配置應該來自高保真的負載測試。

足量的線程數才能保證資源 (CPU) 的利用率：業務型的服務通常都存在一定的 IO 操作（網絡，磁盤等），線程執行過程中會發生等待，CPU 利用率不高，需要增加并發的線程數量，讓更多的線程參與 CPU 的分配，才能提高 CPU 的利用率。服務中 IO 操作越多，等待時長越長，需要的并發線程就越多。對于有 IO 操作的業務型服務，負載測試的線程數可以從 2N（N 是服務器的 CPU 核數）開始。

過多的線程數只會降低系統的 SLA：當線程數已能 100% 利用 CPU 后，增加線程數，線程就無法獲取足夠的 CPU 分配，這樣服務的響應時間就會增大。

在一定范圍內，TP99 還可能滿足 SLA 的要求，系統的吞吐量也會有少量的增加。再持續增加線程數，TP99 就無法滿足系統的要求，系統的吞吐量也會開始下降。

固定的線程數可以保護系統需要承擔的負載能力：固定線程數可以保證系統對 CPU 的利用率限定在一定的負載范圍內，保護系統穩定運行，保證響應時間 TP99，但也限定了系統的并發能力。

合理設置隊列大小可以增加系統的并發度，也不會影響系統 TP99，但會整體拉高服務的響應時間，出現不穩定性的變化，存在風險。

讓 CPU100% 的高負載運行：通常服務對外的 SLA 承諾通常高于服務真實的性能，這是因為我們考慮了基礎設施及依賴服務的不穩定性。

因此，即使 CPU 已經達到了 100%，我們仍然可以增加一定數量的線程數，而不會影響對外的響應時間 TP99 的承諾。這樣可以提高系統的并發能力。雖然系統可以在高負載下運行，但我們需要進一步進行穩定性測試，以提高系統的可靠性。

綜上所述，線程池大小的合理配置需要結合業務需求和系統資源情況進行評估和測試，并預留合理的 buffer 空間，以保證系統穩定運行和滿足用戶的 SLA。

5. 附錄

附錄一：統計指標及術語說明

并發用戶數：同時發起請求的用戶數。

TP 值 (50/90/99/999)：客戶端的 TP 值，單位 ms，數據來源于 Forcebot。

吞吐量 TPS：數據來源于 Forcebot。

CPU 利用率 (%)：數據來源于 PFinder。

JSF 業務線程數：JSF 業務線程池的線程數，如：

fixed/cached：JSF 業務線程池的線程池類型，如：

審核編輯：劉清