問題排查總結
最近一段時間 某台服務器上的一個應用總是隔一段時間就自己掛掉 用top看了看 從重新部署應用開始沒有多長時間CPU占用上升得很快。top命令很快就找到了某個java進程占用過高。
排查步驟
1、使用top定位到占用cpu過高的進行PID
top
2、通過ps aux | grep PID命令
ps -mp pid -o THREAD,tid,time | sort -rn
3、將需要的線程ID轉換為16進制格式
printf "%x\n" tid
4、打印線程的堆棧信息 到了這一步具體看堆棧的日志來定位問題了
jstack pid |grep tid -A 30
案例如下：
1.top 可以看出PID 733進程 的占用CPU 172%
2.查找進程733下的線程 可以看到TID 線程775占用了96%且持有了很長時間 其實到這一步基本上能猜測到應該是 肯定是那段代碼發生了死循環
ps -mp 733 -o THREAD,tid,time | sort -rn
3.線程ID轉換為16進制格式
printf "%x\n" 775
4.查看java 的堆棧信息
jstack 733 |grep 307 -A 30
顯然是 SmsQueueServiceImpl 中的produceMissSms 和 consumeMissSms 方法有問題
和開發一起研究了一下這些代碼，最后開發說應用一啟動的時候 spring初始化的就會執行這一段處理丟失消息的代碼 然后這段死循環代碼 沒有任何作用
解決方法 即 注釋掉whlie(true)這一段代碼
重新部署后 cpu占用就很正常了
