相信大家都遇到過,自己的Java應用運行一段時間就宕機了或者響應請求特別慢。這時候就需要我們了來找出問題所在了。絕大部分都是代碼問題導致的。
一、服務宕機
如果是服務宕機,發生致命問題導致進程已經死掉了,那麼已經訪問不了了,通常都是CPU問題引起的,程序一般會自己生成javacore文件,一般生成位置在/root目錄或jar包同目錄下。JavaCore文件主要保存的是Java應用各線程在某一時刻的運行的位置,即JVM執行到哪一個類、哪一個方法、哪一個行上。
找到這個文件,執行命令
gdb java <文件>
bt
如果文件沒有損壞的話可以看到完整的棧調用信息。就可以定位到問題代碼所在。
我曾經就因爲底層調用的一個geo庫出問題,導致程序直接掛掉,分析core文件可以清晰的看到native方法的調用。
二、服務響應請求慢
出現這個問題一般都是內存溢出,GC線程一直在重複GC,沒有線程來處理用戶請求,或者問題代碼導致CPU佔用過高。
程序崩潰前會生成HeapDump文件,也可以手動生成,HeapDump是一個二進制文件,它保存了某一時刻JVM堆中對象使用情況。
在JVM啓動參數要配置好HeapDump的生成位置和配置打印gc日誌。這樣才能排查問題。
先分析GC日誌
在線分析工具地址:https://gceasy.io/
把gc文件上傳就好了,就可以看到分析結果。重點關注什麼區域的GC佔用最多時間。
離線分析工具:GCViewer 是一款開源的GC日誌分析工具。
如果程序內存溢出,通過分析gc文件可以發現程序內存佔用機會100%而且一直重複GC。
分析HeapDump文件
1、先找到Java應用的pid
ps -ef | grep java 或者 jps -l 查看
2、查看堆內存使用量
jmap -heap <pid>
3、查看Java進程中的每一個線程的情況(linux),可以清晰的看到每一個線程的cpu及內存使用情況
top -Hp <pid>
window下可以藉助工具 Process Explorer,
4、打印線程快照信息,保存到文件xxx.txt中方便查看
jstack <pid> > xxx.txt
參考我的博客:https://blog.csdn.net/Axela30W/article/details/105615288
5、通過top -Hp <pid>看到的線程id是10進制的,我們輸出到xxx.txt中的是16進制,所以需要轉一下,找一個異常線程tid
printf "%x" <tid> 假如輸出爲 1111
6、在xxx.txt文件中查找tid爲1111的棧信息,可以看到這個線程在幹什麼,定位到問題代碼。
7、程序宕機會自動產生dump文件,若沒有宕機就手動導出dump文件
jmap -dump:format=b,file=文件名 <pid>
桌面分析工具:Eclipse Memory Analyzer,它有windows版的和Linux版的
windows下:把HeapDump文件放進去就可以了,分析完後,很直觀的看到當前內存佔用量最高的是某個類的某個參數。持有了多少個對象,這些對象佔用了多少內存,從而定位到問題代碼。
Linux下:先把Eclipse Memory Analyzer版上傳到服務器,解壓,假如/home/mat爲解壓後路徑,執行命令
/home/mat/ParseHeapDump.sh <文件名> org.eclipse.mat.api:suspects prg.eclipse.mat.api:overview org.eclipse.mat.api:top_components
分析完之後會在當前文件生成結果文件。下載到本地查看即可。
沒貼具體的操作圖片,有問題的可以留言交流。
- 我的公衆號:Coding摳腚
- 人生海海,山山而川。