新聞中心
本文轉(zhuǎn)載自微信公眾號「潛行前行」,作者cscw 。轉(zhuǎn)載本文請聯(lián)系潛行前行公眾號。

讓客戶滿意是我們工作的目標,不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴,公司提供的服務項目有:域名注冊、網(wǎng)絡空間、營銷軟件、網(wǎng)站建設(shè)、桂平網(wǎng)站維護、網(wǎng)站推廣。
問題發(fā)現(xiàn)
1 前天大佬通過prometheus發(fā)現(xiàn) tomcat http busy狀態(tài)的線程這幾天呈線性遞增。每一天增加3個
排查問題
1:找到busy線程在哪。通過jvm自帶的 jps 命令可以找到服務對應的進程ID:66182$>$top -Hp 66182
$pidstat -u -p 66182 1 5
大部分的線程都正常,cpu利用率不高,而且線程ID變動快,基本排除 死循環(huán)、CPU 空轉(zhuǎn)的問題
2:既然不是死循環(huán)、CPU空轉(zhuǎn)。那是不是代碼阻塞的問題呢。導出 66182 進程jvm的 stack 文件 jstack -l 66182 > block66182.jstack。因為知道是http 線程的問題。http 的開頭一般都是 http-nio ??梢允褂?grep -A 15 'http-nio' block66182.jstack 輸出一些關(guān)鍵信息。找了很久,多數(shù)http 都是正常狀態(tài)。然后還找到了項目代碼 updateXYDVerifiedCodeByDate 之類的。定位到具體,發(fā)現(xiàn)是一個定時任務
3 查了下 xxl-task 調(diào)度日志。凌晨左右調(diào)度了十次,失敗了三次,和在prometheus發(fā)現(xiàn)的 busy http線程增加的規(guī)律是一致的
4 查找代碼發(fā)現(xiàn)是 CompletableFuture 調(diào)用get阻塞住了。后來改成 future.get(15, TimeUnit.SECONDS);。則每隔 15 秒報錯一次。但是在promethues 監(jiān)控到 verifiedCodeQueryExecutor 的線程隊列是空的。
4.1 promethues 監(jiān)控到的線程隊列數(shù)為空
5 沒有任務 CompletableFuture 的get方法還在執(zhí)行,查看下 verifiedCodeQueryExecutor 的定義。發(fā)現(xiàn),阻塞隊列的拒絕策略 是 DiscardPolicy 丟棄。也就是任務丟棄了不被執(zhí)行,而封裝成的CompletableFuture 自然就不會有結(jié)果返回,因此一直會被阻塞,而改了代碼則是超時返回。真相大白。。。。。
解決問題
1:隊列無限,好像不太好,不接受
2:自定義拒絕策略
- new RejectedExecutionHandler(){
- @Override
- public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
- throw new RuntimeException(" over size error ");
- }
- }
3:但考慮到任務必須被處理掉,任務不能被丟棄啊。so 暫時用 CallerRunsPolicy 策略,executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
4:后面再優(yōu)化
網(wǎng)頁名稱:優(yōu)化排查線程阻塞:CompletableFuture和DiscardPolicy
文章URL:http://www.dlmjj.cn/article/ccsgphc.html


咨詢
建站咨詢
