Java應(yīng)用/JVM宕機(jī)排查步驟操作
相信大家都遇到過(guò),自己的Java應(yīng)用運(yùn)行一段時(shí)間就宕機(jī)了或者響應(yīng)請(qǐng)求特別慢。這時(shí)候就需要我們了來(lái)找出問(wèn)題所在了。絕大部分都是代碼問(wèn)題導(dǎo)致的。
一、服務(wù)宕機(jī)
如果是服務(wù)宕機(jī),發(fā)生致命問(wèn)題導(dǎo)致進(jìn)程已經(jīng)死掉了,那么已經(jīng)訪問(wèn)不了了,通常都是CPU問(wèn)題引起的,程序一般會(huì)自己生成javacore文件,一般生成位置在/root目錄或jar包同目錄下。JavaCore文件主要保存的是Java應(yīng)用各線程在某一時(shí)刻的運(yùn)行的位置,即JVM執(zhí)行到哪一個(gè)類(lèi)、哪一個(gè)方法、哪一個(gè)行上。
找到這個(gè)文件,執(zhí)行命令
gdb java <文件>
bt
如果文件沒(méi)有損壞的話可以看到完整的棧調(diào)用信息。就可以定位到問(wèn)題代碼所在。
我曾經(jīng)就因?yàn)榈讓诱{(diào)用的一個(gè)geo庫(kù)出問(wèn)題,導(dǎo)致程序直接掛掉,分析core文件可以清晰的看到native方法的調(diào)用。
二、服務(wù)響應(yīng)請(qǐng)求慢
出現(xiàn)這個(gè)問(wèn)題一般都是內(nèi)存溢出,GC線程一直在重復(fù)GC,沒(méi)有線程來(lái)處理用戶請(qǐng)求,或者問(wèn)題代碼導(dǎo)致CPU占用過(guò)高。
程序崩潰前會(huì)生成HeapDump文件,也可以手動(dòng)生成,HeapDump是一個(gè)二進(jìn)制文件,它保存了某一時(shí)刻JVM堆中對(duì)象使用情況。
在JVM啟動(dòng)參數(shù)要配置好HeapDump的生成位置和配置打印gc日志。這樣才能排查問(wèn)題。
先分析GC日志
在線分析工具地址:https://gceasy.io/

把gc文件上傳就好了,就可以看到分析結(jié)果。重點(diǎn)關(guān)注什么區(qū)域的GC占用最多時(shí)間。
離線分析工具:GCViewer 是一款開(kāi)源的GC日志分析工具。
如果程序內(nèi)存溢出,通過(guò)分析gc文件可以發(fā)現(xiàn)程序內(nèi)存占用機(jī)會(huì)100%而且一直重復(fù)GC。
分析HeapDump文件
1、先找到Java應(yīng)用的pid
ps -ef | grep java 或者 jps -l 查看
2、查看堆內(nèi)存使用量
jmap -heap <pid>
3、查看Java進(jìn)程中的每一個(gè)線程的情況(linux),可以清晰的看到每一個(gè)線程的cpu及內(nèi)存使用情況
top -Hp <pid>
window下可以借助工具 Process Explorer,

4、打印線程快照信息,保存到文件xxx.txt中方便查看
jstack <pid> > xxx.txt
參考這一篇文章: http://www.dhdzp.com/article/195797.htm
5、通過(guò)top -Hp <pid>看到的線程id是10進(jìn)制的,我們輸出到xxx.txt中的是16進(jìn)制,所以需要轉(zhuǎn)一下,找一個(gè)異常線程tid
printf "%x" <tid> 假如輸出為 1111
6、在xxx.txt文件中查找tid為1111的棧信息,可以看到這個(gè)線程在干什么,定位到問(wèn)題代碼。
7、程序宕機(jī)會(huì)自動(dòng)產(chǎn)生dump文件,若沒(méi)有宕機(jī)就手動(dòng)導(dǎo)出dump文件
jmap -dump:format=b,file=文件名 <pid>
桌面分析工具:Eclipse Memory Analyzer,它有windows版的和Linux版的
windows下:把HeapDump文件放進(jìn)去就可以了,分析完后,很直觀的看到當(dāng)前內(nèi)存占用量最高的是某個(gè)類(lèi)的某個(gè)參數(shù)。持有了多少個(gè)對(duì)象,這些對(duì)象占用了多少內(nèi)存,從而定位到問(wèn)題代碼。
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
分析完之后會(huì)在當(dāng)前文件生成結(jié)果文件。下載到本地查看即可。
以上這篇Java應(yīng)用/JVM宕機(jī)排查步驟操作就是小編分享給大家的全部?jī)?nèi)容了,希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
聊聊Object類(lèi)中的wait()和notify()方法
這篇文章主要介紹了Object類(lèi)中的wait()和notify()方法,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-09-09
java編程之單元測(cè)試(Junit)實(shí)例分析(附實(shí)例源碼)
這篇文章主要介紹了java編程之單元測(cè)試(Junit),結(jié)合實(shí)例形式較為詳細(xì)的分析總結(jié)了Java單元測(cè)試的原理、步驟及相關(guān)注意事項(xiàng),并附帶了完整代碼供讀者下載參考,需要的朋友可以參考下2015-11-11
Springboot集成spring data elasticsearch過(guò)程詳解
這篇文章主要介紹了springboot集成spring data elasticsearch過(guò)程詳解,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-04-04
Java并發(fā)編程中的synchronized關(guān)鍵字詳細(xì)解讀
這篇文章主要介紹了Java并發(fā)編程中的synchronized關(guān)鍵字詳細(xì)解讀,在Java早期版本中,synchronized 屬于 重量級(jí)鎖,效率低下,這是因?yàn)楸O(jiān)視器鎖(monitor)是依賴(lài)于底層的操作系統(tǒng)的Mutex Lock來(lái)實(shí)現(xiàn)的,Java 的線程是映射到操作系統(tǒng)的原生線程之上的,需要的朋友可以參考下2023-12-12
基于SSM框架+Javamail發(fā)送郵件的代碼實(shí)例
本篇文章主要介紹了基于SSM框架+Javamail發(fā)送郵件的代碼實(shí)例,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下。2016-12-12
SpringMvc3+extjs4實(shí)現(xiàn)上傳與下載功能
這篇文章主要為大家詳細(xì)介紹了SpringMvc3+extjs4實(shí)現(xiàn)上傳與下載功能,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-06-06
Java實(shí)現(xiàn)將byte[]轉(zhuǎn)換為File對(duì)象
這篇文章將通過(guò)一個(gè)簡(jiǎn)單的例子為大家演示Java如何實(shí)現(xiàn) byte[] 轉(zhuǎn)換為 File 對(duì)象,并將其上傳到外部服務(wù)器,感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下2025-03-03

