大家好，我是小馬哥。

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

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

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

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

• GitHub：https://github.com/opengoofy/hippo4j
• Gitee：https://gitee.com/agentart/hippo4j

什么是 hippo4j

hippo4j 通過對 JDK ThreadPoolExecutor 線程池增強，以及擴展三方框架底層線程池等功能，為業(yè)務系統(tǒng)提高線上運行保障能力。

小貼士：hippo4j 不止于 Java ThreadPoolExecutor 的增強，Dubbo、RabbitMQ、RocketMQ、Hystrix、Tomcat、Jetty、Undertow 等框架線程池也都有進行監(jiān)控和動態(tài)變更。

什么場景適合用 hippo4j

1. 線程池隨意定義，造成服務器高負載

在系統(tǒng)開發(fā)的過程中，因為涉及到多人協(xié)作，難免會出現(xiàn)信息不互通的情況。在同一個系統(tǒng)，對于線程池來說，常見的是線程池隨意定義。

• 開發(fā)者張三要記錄用戶操作日志，定義了user-log-record-thread-pool；
• 開發(fā)者李四要記錄會員操作日志，定義了member-log-record-thread-pool；
• 開發(fā)者王五要記錄權(quán)限操作日志，定義了power-log-record-thread-pool；
• ……

隨著系統(tǒng)不斷開發(fā)，相同或不同語義的線程池被定義的越來越多，間接導致服務器資源嚴重耗損。

而如果系統(tǒng)中使用 hippo4j，能夠在控制臺查看當前應用已有線程池，是否存在相同語義且業(yè)務可復用線程池實例，避免線程資源過度浪費。

2. 線程池參數(shù)不易評估

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

我覺得犯糾結(jié)的點主要有兩個，無外乎設(shè)置的數(shù)多了或者少了。

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

預估 200ms 執(zhí)行完的任務，可能會 2s 執(zhí)行完，因為任務都在排隊。

任務滿了后，開始執(zhí)行拒絕策略，影響正常業(yè)務。

• 如果超量設(shè)置線程池的參數(shù)，無疑會造成資源浪費，同樣會造成兩種情況。

線程資源也是占用服務器資源的，開啟的多了對服務器有一定壓力。

如果過多的創(chuàng)建線程，當和其它線程池一起執(zhí)行時，服務器 CPU 上下文切換也是個問題。

大家都知道，如果要修改運行中應用線程池參數(shù)，需要停止線上應用，調(diào)整成功后再發(fā)布，而這個過程異常的繁瑣，如果能在運行中動態(tài)調(diào)整線程池的參數(shù)多好。

美團技術(shù)團隊基于這些痛點，推出了動態(tài)線程池的概念，催生了一批動態(tài)線程池框架，hippo4j 也是其一。

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

再比如，壓測時使用 hippo4j 動態(tài)調(diào)整線程池參數(shù)，對于開發(fā)測試來說，也是個不錯的選擇。

3. 線程池運行時報警策略

從線程池運行時監(jiān)控的角度出發(fā)，hippo4j 內(nèi)置 4 種報警策略，線程池活躍度、阻塞隊列容量、拒絕策略觸發(fā)以及任務運行超時報警。

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

hippo4j 支持釘釘、企業(yè)微信和飛書軟件通知，線程池任務運行超時報警示例：

4. 線程池運行時狀態(tài)對開發(fā)者黑盒

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

hippo4j 支持線程池運行時狀態(tài)實時查看，并在核心參數(shù)的基礎(chǔ)上擴展了 負載、內(nèi)存以及拒絕次數(shù) 等關(guān)鍵指標，每次查詢返回線程池當前運行信息。

5. 線程池監(jiān)控

hippo4j 提供了兩種線程池運行時數(shù)據(jù)監(jiān)控方式，分別是：

（1）內(nèi)置數(shù)據(jù)池數(shù)據(jù)采集 + 監(jiān)控，無需依賴任何中間件，由 hippo4j 內(nèi)部集成的方式運行。

（2）使用三方中間件 Prometheus + Grafana 或 ElasticSearch + Grafana 采集和監(jiān)控。

6. 整合 Spring ThreadPoolTaskExecutor

Spring ThreadPoolTaskExecutor 對原生線程池擴展了一部分功能，我認為比較實用有兩個，并且 hippo4j 也已經(jīng)支持。

• 當服務停止時，通知線程池處理剩余任務，并在等待指定時間后強制停止。
• 傳遞線程上下文到線程池執(zhí)行上下文中。

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

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

可能執(zhí)行完了，可能沒有。

Spring 基于以上考慮，注冊了線程池銷毀方法。在應用關(guān)閉時，如果發(fā)現(xiàn)線程池存在任務沒有執(zhí)行完，需要等待一個指定時間。指定時間內(nèi)任務執(zhí)行如果執(zhí)行完畢，皆大歡喜；如果還存在沒有結(jié)束的任務，則丟棄。

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

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

7. 三方框架中間件線程池適配

hippo4j 的目標是兼容所有框架的線程池，并可以提供監(jiān)控和動態(tài)修改的能力。

目前已支持的三方框架線程池列表：

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

支持上述框架線程池的動態(tài)變更參數(shù)和監(jiān)控功能，比如：

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

8. 線程池運行堆棧查看

線程池運行中，任務運行停止，懷疑發(fā)生死鎖或執(zhí)行耗時操作。大多數(shù)程序員會選擇使用命令或者 arthas 查看線程池運行中線程的堆棧，看看其中的 Worker 都在哪個方法卡住了。

hippo4j 基于以上痛點，推出了線程池運行堆棧實時查看功能。

9. 動態(tài)線程池對性能有無影響

這可能是很多開發(fā)者擔心的一個點，在這里統(tǒng)一回復下。

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

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

hippo4j 支持的兩種運行模式

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

（1）hippo4j config

依賴配置中心完成線程池的動態(tài)變更，已支持的配置中心有：Nacos、Apollo、Zookeeper，未來還會接入 Etcd、Consul 等。

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

使用 hippo4j config 模式的優(yōu)點和不足：

優(yōu)點：輕量級引入，可以根據(jù)項目中已有配置中心進行 hippo4j 的集成，無需引入其它服務，即可使用線程池參數(shù)動態(tài)化、運行時監(jiān)控、報警等核心功能。

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

（2）hippo4j server

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

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

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

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

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