生產環境如何快速跟蹤、分析、定位問題-Java

我相信做技術的都會遇到過這樣的問題，生產環境服務遇到宕機的情況下如何去分析問題？比如說JVM內存爆掉、CPU持續高位運行、線程被夯住或線程deadlocks，面對這樣的問題，如何在生產環境第一時間跟蹤分析與定位問題很關鍵。下來讓我們看看通過如下步驟在第一時間分析問題。

CPU占用較高場景

收集當前CPU占用較高的線程信息，執行如下命令：

top -H -p PID -b -d 1 -n 1 > top.log
或
top -H -p PID

結果如下：

 

 

上圖顯示的都是某一個進程內的線程信息，找到cpu消耗最高的線程id，再配合jstack來分析耗cpu的代碼位置，那如何分析呢？

先執行jstack獲取線程信息

jstack -l PID > jstackl.log

將PID（29978）轉成16進制：0x751a，16進制轉換工具很多可以在線隨便搜索一個或者基本功好的自己計算。

打開jstackl.log，查找nid=0x751a的信息，這樣就定位到了具體的代碼位置，這里由於是安全原因我就不貼圖了。

通過上面的步驟就可以輕松的定位那個線程導致cpu過高，當然也可以通過其他方式來定位，下面介紹一個快捷的方式

#線程cpu占用
#!/bin/bash

[ $# -ne 1 ] && exit 1

jstack $1 >/tmp/jstack.log

for cpu_tid in `ps -mp $1 -o THREAD,tid,time|sort -k2nr| sed -n '2,15p' |awk '{print$2"_"$(NF-1)}'`;do

cpu=`echo $cpu_tid | cut -d_ -f1`

tid=`echo $cpu_tid | cut -d_ -f2`

xtid=`printf "%x\n" $tid`

echo -e "\033[31m========================$xtid $cpu%\033[0m"

cat /tmp/jstack.log | sed -n -e "/0x$xtid/,/^$/ p"

#cat /tmp/jstack.log | grep "$xtid" -A15

done

rm /tmp/jstack.log

上述命令會以百分比的方式來顯示每個線程的cpu消耗百分比，這里我就不貼圖了，誰用誰知道。

內存消耗過高場景

收集當前活躍對象數據量信息，執行以下命令獲取

jmap -histo:live pid > jmaplive.log

ps. jmap -histo:live 數據可以多進行幾次，比如說間隔幾分鍾輸出一次，然后對比兩個文件的差異可以看出gc回收的對象，如果多次結果沒有差異並且gc頻繁執行，證明剩余對象在引用無法gc回收，這時就需要對服務進行限流給服務喘氣的機會。

或者收集dump信息，通常這種獲取方式需要較長時間執行，並產生大容量的dump文件，我們會考慮逐步廢掉通過這個文件來分析。執行以下命令獲取

jmap -dump:file=./dump.mdump pid

dump文件通過MAT工具來進行內存泄漏分析。

線程、內存分析工具

上面說過通過jstack生成的線程文件是可以通過工具來直接打開可視化分析的，這里我推薦使用：tda（Thread Dump Analyzer）這個工具可以自行搜索下載。

通過jmap -dump生成的dump文件也是可以通過工具來進行可視化分析的，這里我推薦使用MAT（Memory Analysis Tools）它可以通過eclipse plugin的方式使用或者獨立的下載安裝包使用。