大部分情況下，線程池的運行情況對于使用者來說是個黑盒

運行情況不可知，會導致 生產出現事故問題排查困難，以及線程池參數難以定義

文章圍繞線程池監控展開，討論 線程池如何監控、監控的指標以及監控數據的存儲展示

01如何監控運行數據

設想一下，如果想監控線程池的運行數據，你會怎么操作?這里提供兩種常規思路

線程池運行時埋點，每一次運行任務都進行統計

定時獲取線程池的運行數據

這里我推薦第二種，因為線程池的監控 API 會通過 獲取主鎖來控制結果的相對準確性，性能相對較差，后面會詳細說明

為什么叫相對準確?因為任務和線程的狀態在計算過程中可能會動態變化，只能給到一個近似值，保證不了絕對準確

模擬下定時采集線程池運行時數據的代碼

private ScheduledThreadPoolExecutor collectVesselExecutor; 
 
String collectVesselTaskName = "client.scheduled.collect.data"; 
collectVesselExecutor = new ScheduledThreadPoolExecutor( 
        new Integer(1), 
        ThreadFactoryBuilder.builder().daemon(true).prefix(collectVesselTaskName).build() 
); 
 
// 延遲 initialDelay 后循環調用. scheduleWithFixedDelay 每次執行時間為上一次任務結束時, 向后推一個時間間隔 
collectVesselExecutor.scheduleWithFixedDelay( 
        () -> runTimeGatherTask(), 
        properties.getInitialDelay(), 
        properties.getCollectInterval(), 
        TimeUnit.MILLISECONDS 
); 

一般線程池分為兩種方式創建，Spring Bean 和非 Spring Bean，假設創建的線程池是 Spring 管理的

我們只需要在 Spring 容器啟動成功后，延遲一段時間后開始采集運行數據就 OK 了

不論線程池是否由 Spring 管理，采集的方式大致相同。一種從 Spring 容器取，一種是創建好線程池后放到一個自定義容器

02監控的指標有哪些?

說一下目前 Hippo4J 定義的線程池監控指標，包括不限于。大家有業務中使用到的監控指標都可以討論下

• 線程池當前負載：當前線程數 / 最大線程數
• 線程池峰值負載：當前線程數 / 最大線程數，線程池運行期間最大的負載
• 核心線程數：線程池的核心線程數
• 最大線程數：線程池限制同時存在的線程數
• 當前線程數：當前線程池的線程數
• 活躍線程數：執行任務的線程的大致數目
• 最大出現線程數：線程池中運行以來同時存在的最大線程數
• 阻塞隊列：線程池暫存任務的容器
• 隊列容量：隊列中允許元素的最大數量
• 隊列元素：隊列中已存放的元素數量
• 隊列剩余容量：隊列中還可以存放的元素數量
• 線程池任務完成總量：已完成執行的任務的大致總數
• 拒絕策略執行次數：運行時拋出的拒絕次數總數

這些指標可以幫助我們解決大多數因為線程池而導致的問題排查。但是，事情往往不能盡善盡美

當前線程數、活躍線程數、最大出現線程數、線程池任務完成總量 的線程池 API 會先獲取到 mainLock，然后才開始計算

mainLock 是線程池的主鎖，線程執行、線程銷毀和線程池停止等都會使用到這把鎖

final ReentrantLock mainLock = this.mainLock; 
mainLock.lock(); 
try { 
    xxxxx 
} finally { 
    mainLock.unlock(); 
} 

如果頻繁獲取這把鎖，會導致原有線程池任務執行性能受到影響

所以，我們應該避免頻繁獲取這幾項參數，這也是不使用線程池任務執行埋點最重要的原因

03監控數據存儲

上面的線程池監控指標如果只能支持實時查看，并不能幫忙開發日常排查錯誤

大部分場景下，生產上的問題發現會有延遲。比如 12:30 出現的問題，業務13:00 進行的反饋

為了更好幫助開發排錯，我們需要將線程池的歷史運行數據進行存儲

說到線程池歷史運行數據的存儲，使用 時序數據庫(TSDB) 是最合適的

但大部分情況下，公司不會為了這一個需求搭建或者采購時序數據庫，那就可以使用折中方案，比如說 MySQL、ES 等

我們以 MySQL 為例，his_run_data 歷史運行數據表，建表語句如下：

CREATE TABLE `his_run_data` ( 
  `thread_pool_id` varchar(56) DEFAULT NULL COMMENT '線程池ID', 
  `instance_id` varchar(256) DEFAULT NULL COMMENT '實例ID', 
  `current_load` bigint(20) DEFAULT NULL COMMENT '當前負載', 
  `peak_load` bigint(20) DEFAULT NULL COMMENT '峰值負載', 
  `pool_size` bigint(20) DEFAULT NULL COMMENT '線程數', 
  `active_size` bigint(20) DEFAULT NULL COMMENT '活躍線程數', 
  `queue_capacity` bigint(20) DEFAULT NULL COMMENT '隊列容量', 
  `queue_size` bigint(20) DEFAULT NULL COMMENT '隊列元素', 
  `queue_remaining_capacity` bigint(20) DEFAULT NULL COMMENT '隊列剩余容量', 
  `completed_task_count` bigint(20) DEFAULT NULL COMMENT '已完成任務計數', 
  `reject_count` bigint(20) DEFAULT NULL COMMENT '拒絕次數', 
  `timestamp` bigint(20) DEFAULT NULL COMMENT '時間戳', 
  `gmt_create` datetime DEFAULT NULL COMMENT '創建時間', 
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改時間', 
  PRIMARY KEY (`id`), 
  KEY `idx_group_key` (`tp_id`,`instance_id`) USING BTREE, 
  KEY `idx_timestamp` (`timestamp`) USING BTREE 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='歷史運行數據表'; 

可以看到，建表語句中有三個關鍵字段：

thread_pool_id：表示當前數據的線程池標識

instance_id：應用可能集群部署，標識集群下唯一的線程池

timestamp：記錄線程池運行數據產生時的時間戳

有一個問題，線上的線程池是源源不斷產生運行數據的，遲早不得把表的數據量推到上億?

因為數據是有時效性的，過了一定時間之后，就沒有必要再占用實時的資源

針對上述問題提供兩種解決方案：

• 假設數據存儲 1 天，如果超出這個時間，直接刪除即可
• 同上所述，過期數據可以保留到備份表中，并刪除 his_run_data 數據

可能有的小伙伴還會擔心，數據量太大會不會導致查詢時過慢?

我們可以算一下，假設有 100 個應用，每個應用部署 10 個節點

假設數據有效期為 1 小時，那么可以產出的數據是 72 萬，一天也就是 1728 萬

對于 MySQL 而言，幾千萬數據量以下針對索引的查詢，都不會產生性能瓶頸

04如何定義公共監控?

抽象線程池存儲

上面說到，線程池的采集歷史運行數據在各個應用系統中，數據的存儲、定期刪除是否可以抽象出來，避免重復的工作

如果選擇抽象數據存儲，客戶端節點與服務端之間的交互如下：

• 客戶端定時采集線程池歷史運行數據，將數據打包好發送服務端
• 服務端接收客戶端上報的數據，進行數據入庫持久化存儲
• 服務端定期刪除或存檔客戶端線程池歷史運行數據
• 由服務端統一對外提供線程池運行圖表的數據展示

這里有個小問題，客戶端如何打包發送給服務端?定時采集數據后直接上報是不是可行呢

不推薦采集、上報兩種行為放到一個流程中，好的設計應該是要 分離開職責;而且，如果在上報過程中網絡出現阻塞等等問題，會耽誤采集線程的下一次采集結果

我們可以使用多線程生產、消費模型來做，相信大家初學多線程一定都學過這個設計

// 緩沖隊列 
private BlockingQueue<Message> messageCollectVessel  = new ArrayBlockingQueue(bufferSize); 
 
// 生產者 
Message message = collector.collectMessage(); 
boolean offer = messageCollectVessel.offer(message); 
if (!offer) { 
    log.warn("Buffer data starts stacking data..."); 
} 
 
// 消費者 
while (true) { 
    try { 
        Message message = messageCollectVessel.take(); 
        messageSender.send(message); 
    } catch (Throwable ex) { 
        log.error("Consumption buffer container task failed. Number of buffer container tasks :: {}", messageCollectVessel.size(), ex); 
    } 
} 

創建阻塞緩沖隊列，由定時線程池采集歷史運行數據，并放到緩沖隊列中;然后起一個線程，循環消費即可

極端情況下緩沖隊列元素會出現堆積，最新采集的線程池數據也就無法插入成功，為了不影響客戶端的運行，僅做異常警告處理

使用最新抽象出來的客戶端、服務端交互流程，有以下幾個優點

• 數據的存儲和查詢展示由服務端提供功能，減輕客戶端壓力和重復工作量
• 歷史運行數據的刪除或備份操作由服務端統一執行
• 不同的項目不需要為線程池歷史運行數據分別創建表結構存儲
• 形成交互規范，避免業務發散單獨開發，中心化的設計更利于技術的迭代和管理

監控圖表展示

不同公司對于線程池的監控不盡相同，出于各種考慮，會將監控封裝成最符合自己業務場景的流程

Hippo4J 從最基本的指標出發，封裝出了最小代價的監控體系，并提供可視化頁面的圖標展示

有興趣可以查看 Hippo4J 框架官網介紹

Site：https://www.hippox.cn

還有一個功能點，考慮到很多公司搭建了一套監控體系，其中以 Prometheus + Grafana 為主

后續 Hippo4J 會接入 Prometheus，應用內部存儲線程池的運行數據，適配 Prometheus 采集存儲，最終展示到 Grafana

05總結回顧

線程池作為企業級應用廣泛的技術，對它的監控是不可或缺的穩定性保障之一