聊聊動態執行緒池的9個場景

• 2022 年 8 月 25 日
• 筆記

聊聊動態執行緒池的9個場景

大家好，我是小馬哥。

執行緒池是一種基於 池化思想管理執行緒 的工具，使用執行緒池可以減少 創建銷毀執行緒的開銷，避免執行緒過多導致 系統資源耗盡。在 高並發以及大批量 的任務處理場景，執行緒池的使用是必不可少的。

如果有在項目中實際使用執行緒池，相信你可能會遇到以下痛點：

1. 執行緒池隨便定義，執行緒資源過多，造成伺服器高負載。
2. 執行緒池參數不易評估，隨著業務的並發提升，業務面臨出現故障的風險。
3. 執行緒池任務執行時間超過平均執行周期，開發人員無法感知。
4. 執行緒池任務堆積，觸發拒絕策略，影響既有業務正常運行。
5. 當業務出現超時、熔斷等問題時，因為沒有監控，無法確定是不是執行緒池引起。
6. 原生執行緒池不支援運行時變數的傳遞，比如 MDC 上下文遇到執行緒池就 GG。
7. 無法執行優雅關閉，當項目關閉時，大量正在運行的執行緒池任務被丟棄。
8. 執行緒池運行中，任務執行停止，懷疑發生死鎖或執行耗時操作，但是無從下手。

基於以上諸多痛點，小馬哥著手 hippo4j 的開發，致力於打造標準執行緒池 動態變更 和 監控 的中間件框架。

GitHub：//github.com/opengoofy/hippo4j

Gitee：//gitee.com/agentart/hippo4j

什麼是 hippo4j

hippo4j 通過對 JDK ThreadPoolExecutor 執行緒池增強，以及擴展三方框架底層執行緒池等功能，為業務系統提高線上運行保障能力。

小貼士：hippo4j 不止於 Java ThreadPoolExecutor 的增強，Dubbo、RabbitMQ、RocketMQ、Hystrix、Tomcat、Jetty、Undertow 等框架執行緒池也都有進行監控和動態變更。

什麼場景適合用 hippo4j

1. 執行緒池隨意定義，造成伺服器高負載

在系統開發的過程中，因為涉及到多人協作，難免會出現資訊不互通的情況。在同一個系統，對於執行緒池來說，常見的是執行緒池隨意定義。

• 開發者張三要記錄用戶操作日誌，定義了 user-log-record-thread-pool；
• 開發者李四要記錄會員操作日誌，定義了 member-log-record-thread-pool；
• 開發者王五要記錄許可權操作日誌，定義了 power-log-record-thread-pool；
• ……

隨著系統不斷開發，相同或不同語義的執行緒池被定義的越來越多，間接導致伺服器資源嚴重耗損。

而如果系統中使用 hippo4j，能夠在控制台查看當前應用已有執行緒池，是否存在相同語義且業務可復用執行緒池實例，避免執行緒資源過度浪費。

2. 執行緒池參數不易評估

業務中使用了執行緒池，十個程式設計師可能有九個都在犯嘀咕，這執行緒池的配置應該如何選擇？

我覺得犯糾結的點主要有兩個，無外乎設置的數 多了 或者 少了。

1. 如果預設的執行緒數或阻塞隊列數量少了，當業務量上來，會遇到兩種情況，不管哪一種對業務來說都是不能接受的。
   1. 預估 200ms 執行完的任務，可能會 2s 執行完，因為任務都在排隊。
   2. 任務滿了後，開始執行拒絕策略，影響正常業務。
2. 如果超量設置執行緒池的參數，無疑會造成資源浪費，同樣會造成兩種情況。
   1. 執行緒資源也是佔用伺服器資源的，開啟的多了對伺服器有一定壓力。
   2. 如果過多的創建執行緒，當和其它執行緒池一起執行時，伺服器 CPU 上下文切換也是個問題。

大家都知道，如果要修改運行中應用執行緒池參數，需要停止線上應用，調整成功後再發布，而這個過程異常的繁瑣，如果能在運行中動態調整執行緒池的參數多好。

美團技術團隊基於這些痛點，推出了 動態執行緒池 的概念，催生了一批動態執行緒池框架，hippo4j 也是其一。

如果應用是集群部署，hippo4j 可以選擇修改執行緒池 某一實例，或者修改 集群全部實例，運行時生效，不需要再重啟服務。

再比如，壓測時使用 hippo4j 動態調整執行緒池參數，對於開發測試來說，也是個不錯的選擇。

3. 執行緒池運行時報警策略

從執行緒池運行時監控的角度出發，hippo4j 內置 4 種報警策略，執行緒池活躍度、阻塞隊列容量、拒絕策略觸發以及任務運行超時報警。

• 執行緒池活躍度：假設閾值設置 80%，執行緒池最大執行緒數 10，當執行緒數達到 8 發起報警。
• 阻塞隊列容量：假設閾值設置 80%，阻塞隊列容量 100，當容量達到 80 發起報警。
• 觸發拒絕策略：當執行緒池任務觸發了拒絕策略時，發起拒絕策略報警。
• 任務運行超時：假設單個任務超時為 1000ms，任務執行超過該時間發起報警。

hippo4j 支援釘釘、企業微信和飛書軟體通知，執行緒池任務運行超時報警示例：

4. 執行緒池運行時狀態對開發者黑盒

執行緒池在服務運行過程中，對開發者來說是一個完全的黑盒。開發者無法得知執行緒池的參數變化，比如阻塞隊列數量或者完成任務數等核心參數，這對於排查問題來說並不友好。

hippo4j 支援執行緒池運行時狀態實時查看，並在核心參數的基礎上擴展了 負載、記憶體以及拒絕次數 等關鍵指標，每次查詢返回執行緒池當前運行資訊。

5. 執行緒池監控

hippo4j 提供了兩種執行緒池運行時數據監控方式，分別是：

1、內置數據池數據採集 + 監控，無需依賴任何中間件，由 hippo4j 內部集成的方式運行。

2、使用三方中間件 Prometheus 或 ElasticSearch + Grafana 採集和監控。

6. 整合 Spring ThreadPoolTaskExecutor

Spring ThreadPoolTaskExecutor 對原生執行緒池擴展了一部分功能，我認為比較實用有兩個，並且 hippo4j 也已經支援。

1. 當服務停止時，通知執行緒池處理剩餘任務，並在等待指定時間後強制停止。
2. 傳遞執行緒上下文到執行緒池執行上下文中。

第一個是實際使用中很核心的功能，減少了執行緒池丟棄任務的可能，這裡重點說明下。

我們平時在停止應用時，有沒有這樣一個考慮，執行緒池中的任務真的都執行完成了嗎？

可能執行完了，可能沒有。

Spring 基於以上考慮，註冊了執行緒池銷毀方法。在應用關閉時，如果發現執行緒池存在任務沒有執行完，需要等待一個指定時間。指定時間內任務執行如果執行完畢，皆大歡喜；如果還存在沒有結束的任務，則丟棄。

為什麼會丟棄任務而不是再等等？

因為如果執行緒池任務長時間執行，會影響整個應用的停止，進行了折中處理。

7. 三方框架中間件執行緒池適配

hippo4j 的目標是兼容所有框架的執行緒池，並可以提供監控和動態修改的能力。

目前已支援的三方框架執行緒池列表：

• Apache Dubbo
• Alibaba Dubbo
• RabbitMQ
• Apache RocketMQ
• SpringCloud Stream RocketMQ
• SpringCloud Hystrix
• Tomcat
• Jetty
• Undertow

支援上述框架執行緒池的動態變更參數和監控功能，比如：

未來 hippo4j 會支援更多三方框架執行緒池，如果你有好的想法也可以和我溝通。

8. 執行緒池運行堆棧查看

執行緒池運行中，任務運行停止，懷疑發生死鎖或執行耗時操作。大多數程式設計師會選擇使用命令或者 arthas 查看執行緒池運行中執行緒的堆棧，看看其中的 Worker 都在哪個方法卡住了。

hippo4j 基於以上痛點，推出了執行緒池運行堆棧實時查看功能。

9. 動態執行緒池對性能有無影響

這可能是很多開發者擔心的一個點，在這裡統一回復下。

hippo4j 僅對執行緒池做部分核心功能增強，沒有修改任務執行源程式碼流程，可以保證絕對的安全。

其次，hippo4j 上述的功能，都是與執行緒池執行任務主流程外擴展的，不會影響執行緒池正常的執行性能。

hippo4j 支援的兩種運行模式

hippo4j 為用戶提供了兩種運行模式，分別是 輕量級的配置中心接入，和功能更齊全的 服務端接入，下面都來說說各自的優缺點。

1. hippo4j config

依賴配置中心完成執行緒池的動態變更，已支援的配置中心有：Nacos、Apollo、Zookeeper，未來還會接入 Etcd、Consul 等。

另外，hippo4j 已支援用戶自定義配置中心實現，如果使用公司自研或其它配置中心，也可以極小工作量進行引入。

使用 hippo4j config 模式的優點和不足：

1. 優點：輕量級引入，可以根據項目中已有配置中心進行 hippo4j 的集成，無需引入其它服務，即可使用執行緒池參數動態化、運行時監控、報警等核心功能。
2. 不足：缺少可視化控制台頁面，上文中描述的諸多功能不能使用。

2. hippo4j server

需要部署 hippo4j Jar 包，涵蓋上文中描述的所有功能。

因為服務端內部實現了配置中心和註冊中心（參考 nacos 和 eureka 實現），所以它不依賴任何三方中間件。

1. 優點：功能齊備，可以享受更多的服務和便利。如果應用啟動的是集群，可以指定其中某一個實例的執行緒池修改，而 config 則是整個集群變更。
2. 不足：相比較 hippo4j config，需要額外部署一個 jar 包，增加了部署工作量。

如果最初使用 hippo4j config，想要切換到 server，兩者在進行替換的時候，無需修改業務程式碼。

使用建議：根據公司情況選擇，如果基本功能可以滿足使用，選擇 hippo4j config 使用即可；如果希望更多的功能，可以選擇 hippo4j server。

項目發展近況

開源項目發展離不開用戶和貢獻者的支援，小馬哥梳理出最近 hippo4j 發展近況：

• GitHub、Gitee 收穫 3.2k+ star，810+ fork。
• 2022.4.12 Gitee 評選 GVP（最有價值開源項目）。
• 58 名項目貢獻者為 hippo4j 添磚加瓦，這裡重點感謝。
• 16 家使用登記公司，生產環境正式運行 hippo4j。
• 通過墨菲安全掃描，無任何程式碼安全漏洞隱患。

文末結語

最後總結下，開源作者犧牲了每天下班和周六日的時間做開源項目，如果覺得有用，麻煩各位大佬在以下兩個平台 star 支援下，灰常感謝～

GitHub：//github.com/opengoofy/hippo4j

Gitee：//gitee.com/agentart/hippo4j