大家好，我是小馬哥。

執行緒池是一種基於

池化思想管理執行緒

的工具，使用執行緒池可以減少

建立銷燬執行緒的開銷

，避免執行緒過多導致

系統資源耗盡

。在

高併發以及大批次

的任務處理場景，執行緒池的使用是必不可少的。

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

執行緒池隨便定義，執行緒資源過多，造成伺服器高負載。

執行緒池引數不易評估，隨著業務的併發提升，業務面臨出現故障的風險。

執行緒池任務執行時間超過平均執行週期，開發人員無法感知。

執行緒池任務堆積，觸發拒絕策略，影響既有業務正常執行。

當業務出現超時、熔斷等問題時，因為沒有監控，無法確定是不是執行緒池引起。

原生執行緒池不支援執行時變數的傳遞，比如 MDC 上下文遇到執行緒池就 GG。

無法執行優雅關閉，當專案關閉時，大量正在執行的執行緒池任務被丟棄。

執行緒池執行中，任務執行停止，懷疑發生死鎖或執行耗時操作，但是無從下手。

基於以上諸多痛點，小馬哥著手 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。 執行緒池引數不易評估

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

我覺得犯糾結的點主要有兩個，無外乎設定的數

多了

或者

少了

。

如果預設的執行緒數或阻塞佇列數量少了，當業務量上來，會遇到兩種情況，不管哪一種對業務來說都是不能接受的。

預估

200ms

執行完的任務，可能會

2s

執行完，因為任務都在排隊。

任務滿了後，開始執行拒絕策略，影響正常業務。

如果超量設定執行緒池的引數，無疑會造成資源浪費，同樣會造成兩種情況。

執行緒資源也是佔用伺服器資源的，開啟的多了對伺服器有一定壓力。

如果過多的建立執行緒，當和其它執行緒池一起執行時，伺服器 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 也已經支援。

當服務停止時，通知執行緒池處理剩餘任務，並在等待指定時間後強制停止。

傳遞執行緒上下文到執行緒池執行上下文中。

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

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

可能執行完了，可能沒有

。

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 模式的優點和不足：

優點：輕量級引入，可以根據專案中已有配置中心進行 hippo4j 的整合，無需引入其它服務，即可使用執行緒池引數動態化、執行時監控、報警等核心功能。

不足：缺少視覺化控制檯頁面，上文中描述的諸多功能不能使用。

2。 hippo4j server

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

因為服務端內部實現了配置中心和註冊中心（參考

nacos

和

eureka

實現），所以它不依賴任何三方中介軟體。

優點：功能齊備，可以享受更多的服務和便利。如果應用啟動的是叢集，可以指定其中某一個例項的執行緒池修改，而 config 則是整個叢集變更。

不足：相比較 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：

https：//github。com/opengoofy/hippo4j

Gitee：

https：//gitee。com/agentart/hippo4j