最近一段時間 某臺服務器上的一個應用總是隔一段時間就自己掛掉 用top看了看 從重新部署應用開始沒有多長時間cpu占用上升得很快
排查步驟
1.使用top 定位到占用cpu高的進程pid
top
2.通過ps aux | grep pid命令
獲取線程信息，并找到占用cpu高的線程
ps -mp pid -o thread,tid,time | sort -rn
3.將需要的線程id轉換為16進制格式
printf "%x\n" tid
4.打印線程的堆棧信息 到了這一步具體看堆棧的日志來定位問題了
jstack pid |grep tid -a 30
top 可以看出pid 733進程 的占用cpu 172%
查找進程733下的線程 可以看到tid 線程775占用了96%且持有了很長時間 其實到這一步基本上能猜測到應該是 肯定是那段代碼發生了死循環
ps -mp 733 -o thread,tid,time | sort -rn
線程id轉換為16進制格式
printf "%x\n" 775
查看java 的堆棧信息
jstack 733 |grep 307 -a 30
顯然是 smsqueueserviceimpl 中的producemisssms 和 consumemisssms 方法有問題
一下為精簡的部分代碼
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
/** * created by dongxc on 2015/7/7. 通知消息隊列 */@service("smsqueueservice")public class smsqueueserviceimpl { // 生產異常隊列方法 public void producemisssms(smslogdo smslogdo) { /* * try{ string key = enumredisprefix.sms_queue_miss_deal.getvalue(); boolean result = redisservice.lpush(key, * smslogdo, 0); if(result==false){ logger.error("通知消息異常隊列生產消息返回失敗！"+smslogdo.getid()); } }catch(exception e){ * logger.error("通知消息異常隊列生產消息失敗！", e); } */ } // 消費異常隊列方法 public smslogdo consumemisssms() { try { string destkey = enumredisprefix.sms_queue_miss_deal.getvalue(); smslogdo smslogdo = new smslogdo(); object obj = null; if (obj == null) { return null; } else { smslogdo = (smslogdo) obj; } return smslogdo; } catch (exception e) { logger.error("通知消息隊列消費方法失敗！", e); return null; } }} |
從很有年代感的垃圾代碼來看 這兩個方法并沒有什么問題 繼續往調用這兩個方法的上層排查
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
/** * created by dongxc on 2015/7/7. * 消息通知監控線程 */@service("smsmonitorcomsumer")public class smsmonitorcomsumerimpl { @autowired private smsqueueserviceimpl smsqueueservice; //取隊列里的任務消費 @transactional(propagation= propagation.not_supported) public void run() { while (true) { try { smslogdo smslogdo = smsqueueservice.consumemisssms(); boolean result = false; if(smslogdo!=null){ long diff = (new date()).gettime() - smslogdo.getsendtime().gettime() ; long min = diff%(1000*24*60*60)%(1000*60*60)/(1000*60);//計算差多少分鐘 if(min>5){ result = true; } } if(result){ smsqueueservice.producesms(smslogdo); }else{ smsqueueservice.producemisssms(smslogdo); } } catch (exception ex) { try{ thread.sleep(3000); }catch(exception e){ //logger.error("發送站內信息短信時線程執行失敗2！", e); } } } }} |
很顯然 這里有一個while(true) 基本定位到問題了 while里面完全是沒有用的代碼
繼續往上層看誰來調用
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
/** * created by dongxc on 2015/7/7. * 通知消息隊列 */@service("smslogrunthread")public class smslogrunthreadimpl { public int flag; @autowired private smslogconsumerimpl smslogconsumer; @autowired private smsmonitorcomsumerimpl smsmonitorcomsumer; @postconstruct public void init() { if(ip!=""&&host!=""&&ip.equals(host)){ thread thread = new thread(){ public void run() { smslogconsumer.run(); } }; thread.start(); thread thread1 = new thread(){ public void run() { smsmonitorcomsumer.run(); } }; thread1.start(); } }} |
在應用一啟動的時候 spring初始化的就會執行這一段處理丟失消息的代碼 然后這段死循環代碼 沒有任何作用
解決方法 即 注釋掉whlie(true)這一段代碼
案例一下,其實之前也遇到過cpu占用很高的問題, 但是那次是 頻繁的gc導致的
其實排查問題 的過程中也是在不斷的學習的過程
原文鏈接：https://www.cnblogs.com/xxj0316/p/9448987.html
