圖20 setCorePoolSize方法執(zhí)行流程
線程池內(nèi)部會處理好當前狀態(tài)做到平滑修改 ， 其他幾個方法限于篇幅 ， 這里不一一介紹 。重點是基于這幾個public方法 ， 我們只需要維護ThreadPoolExecutor的實例 ， 并且在需要修改的時候拿到實例修改其參數(shù)即可 ?；谝陨系乃悸?nbsp;， 我們實現(xiàn)了線程池參數(shù)的動態(tài)化、線程池參數(shù)在管理平臺可配置可修改 ， 其效果圖如下圖所示：
圖21 可動態(tài)修改線程池參數(shù)
用戶可以在管理平臺上通過線程池的名字找到指定的線程池 ， 然后對其參數(shù)進行修改 ， 保存后會實時生效 。目前支持的動態(tài)參數(shù)包括核心數(shù)、最大值、隊列長度等 。除此之外 ， 在界面中 ， 我們還能看到用戶可以配置是否開啟告警、隊列等待任務告警閾值、活躍度告警等等 。關于監(jiān)控和告警 ， 我們下面一節(jié)會對齊進行介紹 。
線程池監(jiān)控
除了參數(shù)動態(tài)化之外 ， 為了更好地使用線程池 ， 我們需要對線程池的運行狀況有感知 ， 比如當前線程池的負載是怎么樣的？分配的資源夠不夠用？任務的執(zhí)行情況是怎么樣的？是長任務還是短任務？
基于對這些問題的思考 ， 動態(tài)化線程池提供了多個維度的監(jiān)控和告警能力 ， 包括：線程池活躍度、任務的執(zhí)行Transaction（頻率、耗時）、Reject異常、線程池內(nèi)部統(tǒng)計信息等等 ， 既能幫助用戶從多個維度分析線程池的使用情況 ， 又能在出現(xiàn)問題第一時間通知到用戶 ， 從而避免故障或加速故障恢復 。
1. 負載監(jiān)控和告警
線程池負載關注的核心問題是：基于當前線程池參數(shù)分配的資源夠不夠 。對于這個問題 ， 我們可以從事前和事中兩個角度來看 。事前 ， 線程池定義了“活躍度”這個概念 ， 來讓用戶在發(fā)生Reject異常之前能夠感知線程池負載問題 ， 線程池活躍度計算公式為：線程池活躍度 =
activeCount/maximumPoolSize 。這個公式代表當活躍線程數(shù)趨向于maximumPoolSize的時候 ， 代表線程負載趨高 。
事中 ， 也可以從兩方面來看線程池的過載判定條件 ， 一個是發(fā)生了Reject異常 ， 一個是隊列中有等待任務（支持定制閾值） 。以上兩種情況發(fā)生了都會觸發(fā)告警 ， 告警信息會通過大象推送給服務所關聯(lián)的負責人 。
圖22 大象告警通知
2. 任務級精細化監(jiān)控
在傳統(tǒng)的線程池應用場景中 ， 線程池中的任務執(zhí)行情況對于用戶來說是透明的 。比如在一個具體的業(yè)務場景中 ， 業(yè)務開發(fā)申請了一個線程池同時用于執(zhí)行兩種任務 ， 一個是發(fā)消息任務、一個是發(fā)短信任務 ， 這兩類任務實際執(zhí)行的頻率和時長對于用戶來說沒有一個直觀的感受 ， 很可能這兩類任務不適合共享一個線程池 ， 但是由于用戶無法感知 ， 因此也無從優(yōu)化 。動態(tài)化線程池內(nèi)部實現(xiàn)了任務級別的埋點 ， 且允許為不同的業(yè)務任務指定具有業(yè)務含義的名稱 ， 線程池內(nèi)部基于這個名稱做Transaction打點 ， 基于這個功能 ， 用戶可以看到線程池內(nèi)部任務級別的執(zhí)行情況 ， 且區(qū)分業(yè)務 ， 任務監(jiān)控示意圖如下圖所示：
推薦閱讀
- cad卸載工具怎么用 cad卸載干凈的教程
- qq營銷工具源碼 最有效推廣的方式
- 目前三防手機哪個好 最好的三防手機品牌
- 哪些人不宜喝酒
- 艾灸真的可以治療哮喘嗎
- 面包硬的其他原因
- 釣鱸魚的餌料比較好用的有哪些
- 黃皮果的食用方法
- 骨盆前傾該怎么練呢
- 骨盆前傾是怎么形成的呢