相信大家都遇到過，自己的Java應(yīng)用運行一段時間就宕機了或者響應(yīng)請求特別慢。這時候就需要我們了來找出問題所在了。絕大部分都是代碼問題導(dǎo)致的。

一、服務(wù)宕機

如果是服務(wù)宕機，發(fā)生致命問題導(dǎo)致進程已經(jīng)死掉了，那么已經(jīng)訪問不了了，通常都是CPU問題引起的，程序一般會自己生成javacore文件，一般生成位置在/root目錄或jar包同目錄下。JavaCore文件主要保存的是Java應(yīng)用各線程在某一時刻的運行的位置，即JVM執(zhí)行到哪一個類、哪一個方法、哪一個行上。

找到這個文件，執(zhí)行命令

gdb java

bt

如果文件沒有損壞的話可以看到完整的棧調(diào)用信息。就可以定位到問題代碼所在。

我曾經(jīng)就因為底層調(diào)用的一個geo庫出問題，導(dǎo)致程序直接掛掉，分析core文件可以清晰的看到native方法的調(diào)用。

二、服務(wù)響應(yīng)請求慢

出現(xiàn)這個問題一般都是內(nèi)存溢出，GC線程一直在重復(fù)GC，沒有線程來處理用戶請求，或者問題代碼導(dǎo)致CPU占用過高。

程序崩潰前會生成HeapDump文件，也可以手動生成，HeapDump是一個二進制文件，它保存了某一時刻JVM堆中對象使用情況。

在JVM啟動參數(shù)要配置好HeapDump的生成位置和配置打印gc日志。這樣才能排查問題。

先分析GC日志

把gc文件上傳就好了，就可以看到分析結(jié)果。重點關(guān)注什么區(qū)域的GC占用最多時間。

離線分析工具：GCViewer 是一款開源的GC日志分析工具。

如果程序內(nèi)存溢出，通過分析gc文件可以發(fā)現(xiàn)程序內(nèi)存占用機會100%而且一直重復(fù)GC。

分析HeapDump文件

1、先找到Java應(yīng)用的pid

ps -ef | grep java 或者 jps -l 查看

2、查看堆內(nèi)存使用量

jmap -heap

3、查看Java進程中的每一個線程的情況(linux)，可以清晰的看到每一個線程的cpu及內(nèi)存使用情況

top -Hp

window下可以借助工具 Process Explorer，

4、打印線程快照信息,保存到文件xxx.txt中方便查看

jstack > xxx.txt

5、通過top -Hp 看到的線程id是10進制的，我們輸出到xxx.txt中的是16進制，所以需要轉(zhuǎn)一下，找一個異常線程tid

printf "%x" 假如輸出為 1111

6、在xxx.txt文件中查找tid為1111的棧信息，可以看到這個線程在干什么，定位到問題代碼。

7、程序宕機會自動產(chǎn)生dump文件，若沒有宕機就手動導(dǎo)出dump文件

jmap -dump:format=b,file=文件名

桌面分析工具：Eclipse Memory Analyzer，它有windows版的和Linux版的

windows下：把HeapDump文件放進去就可以了，分析完后，很直觀的看到當(dāng)前內(nèi)存占用量最高的是某個類的某個參數(shù)。持有了多少個對象，這些對象占用了多少內(nèi)存，從而定位到問題代碼。

Linux下：先把Eclipse Memory Analyzer版上傳到服務(wù)器，解壓，假如/home/mat為解壓后路徑，執(zhí)行命令

/home/mat/ParseHeapDump.sh org.eclipse.mat.api:suspects prg.eclipse.mat.api:overview

org.eclipse.mat.api:top_components

分析完之后會在當(dāng)前文件生成結(jié)果文件。下載到本地查看即可。

以上這篇Java應(yīng)用/JVM宕機排查步驟操作就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

總結(jié)

以上是生活随笔為你收集整理的java 宕机_Java应用/JVM宕机排查步骤操作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。