大家好，我是小馬哥。

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

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

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

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

• GitHub：https://github.com/opengoofy/hippo4j
• Gitee：https://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. 線程池參數不易評估

業務中使用了線程池，十個程序員可能有九個都在犯嘀咕，這線程池的配置應該如何選擇？

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

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

預估 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 + Grafana 或 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。