如何用jvm程序執(zhí)行慢診斷手冊(cè)

本篇內(nèi)容介紹了“如何用jvm程序執(zhí)行慢診斷手冊(cè)”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

生產(chǎn)環(huán)境最多的幾種事故之一就是程序執(zhí)行慢，如果是web服務(wù)的話，表現(xiàn)就是響應(yīng)時(shí)間長(zhǎng)。本文分享，從業(yè)多年形成的排查守則。

診斷步驟

系統(tǒng)資源查看

首先是系統(tǒng)資源查看，而且必須是在第一步。因?yàn)楹芏嗍鹿识际亲铋_始慢后面就會(huì)出現(xiàn)卡死，被系統(tǒng)殺死，程序拋出異常結(jié)束等等情況，當(dāng)時(shí)的狀態(tài)沒法保存下來，不行進(jìn)行復(fù)盤，所以第一步先查看系統(tǒng)的資源，如果出現(xiàn)緊張情況，趕緊把狀態(tài)保存。

top命令

查看基本就是top命令，可以看到系統(tǒng)cpu,內(nèi)存等資源情況。經(jīng)過查看系統(tǒng)資源大概可以分為以下情況。

問題：cpu使用率過高。

如果發(fā)現(xiàn)cpu成為了瓶頸的話，必須馬上進(jìn)行線程情況和當(dāng)時(shí)cpu占用情況的保存。在糟糕的情況下，cpu可能被占滿，那時(shí)候ssh都登錄不上去了，就沒法獲取當(dāng)時(shí)的情況。

使用top -Hp pid獲取線程cpu使用率高的tid
printf "%x\n" tid,獲取線程id的16進(jìn)制主要是為了在jstack中查看
jstack pid|grep tid(16)

然后就會(huì)把線程cpu使用率特別高的線程棧打出來，然后可以分析這段邏輯了。

內(nèi)存使用率過高或者沒有系統(tǒng)資源占用過高

jmap -dump:format=b,file=heapdump.bin pid

這里必須打dump的原因是res過高，可能出發(fā)系統(tǒng)的oom killer，進(jìn)程可能被系統(tǒng)殺死，此時(shí)不獲取，可能進(jìn)程就會(huì)被殺死了。如果不是系統(tǒng)資源問題，堆dump以后也是要用的。

堆占用查看

jstat -gc -h 10 pid 1000
jstat -gcutil -h 10 pid 1000
jstat -gccause -h 10 pid 1000

這里一般是開三個(gè)窗口對(duì)比看數(shù)據(jù)的。-gc主要是關(guān)注堆的分區(qū)總大小。-gcutil主要是關(guān)注已使用的百分比。-gccause主要是關(guān)注fgc次數(shù)，時(shí)間以及gc原因。

內(nèi)存問題的分類就比較多了，造成問題的卡頓的根本其實(shí)是gc問題。stw的時(shí)候虛擬機(jī)停頓了，導(dǎo)致反應(yīng)不過來了。

問題：堆內(nèi)存占用空間接近滿

這種情況就利用mat去查看dump分析吧，可能出現(xiàn)內(nèi)存使用不合理或者內(nèi)存泄漏，這里需要根據(jù)代碼來分析。

問題：perm,metaspace占用接近滿

jps -lvm

查看一下jvm參數(shù)設(shè)置，很可能是參數(shù)設(shè)置不合理，-XX:MetaspaceSize是發(fā)生gc的最小空間，這里是不是設(shè)置太小。MaxMetaspaceSize，MaxPermSize的值是否設(shè)置太小。java6如果設(shè)置都不小而且還占滿了，那就得檢測(cè)代碼里是不是在運(yùn)行時(shí)常量池加了字符串。1.7，1.8就考慮是不是業(yè)務(wù)用了什么字節(jié)碼生成技術(shù)，動(dòng)態(tài)做了一些字節(jié)碼操作。

問題：system.gc()

gccause查看gc的原因是system.gc()。需要檢測(cè)是否用了rmi,使用了直接內(nèi)存，或者業(yè)務(wù)代碼調(diào)用了system.gc()。直接內(nèi)存查看現(xiàn)在沒有現(xiàn)成的工具?？梢允褂梦以趃ithub上放著的小工具查看。地址如下https://github.com/xpbob/jstatassist

問題：gc頻繁但不是system.gc()

空間都不是特別緊張，但是gc次數(shù)頻繁，并且不是system.gc()。那可能就是gc參數(shù)設(shè)置不對(duì)了，例如cms，老年代回收是一個(gè)2秒一次的輪訓(xùn)操作，很有可能是現(xiàn)在的空間占用每次都是滿足gc的條件的，于是出現(xiàn)了這種情況。

問題：gc時(shí)間特別長(zhǎng)

gc時(shí)間特別長(zhǎng)，這個(gè)就從gc算法選擇還有內(nèi)存情況來協(xié)調(diào)參數(shù)吧。但是有兩個(gè)特例，cms和g1。這兩個(gè)垃圾回收器都是有單線程回收的算法的可能的，這里需要gc日志分析確認(rèn)。

問題：堆占用不大，res特別大

這種情況可能性太大，常見的是jni，jna操作，mmap文件，直接內(nèi)存使用，jdk的bug。需要根據(jù)實(shí)際情況來分析。

問題： 業(yè)務(wù)問題

如果以上表現(xiàn)都沒有的話，那需要不斷的打jstack去看線程棧的變化。這個(gè)只能是結(jié)合業(yè)務(wù)來看。

“如何用jvm程序執(zhí)行慢診斷手冊(cè)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！