如何通過jstack與jmap分析一次線上故障

這期內容當中小編將會給大家帶來有關如何通過jstack與jmap分析一次線上故障，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

下面是線上機器的cpu使用率，可以看到從4月8日開始，隨著時間cpu使用率在逐步增高，最終使用率達到100%導致線上服務不可用，后面重啟了機器后恢復。

簡單分析下可能出問題的地方，分為5個方向：

1.系統本身代碼問題

2.內部下游系統的問題導致的雪崩效應

3.上游系統調用量突增

4.http請求第三方的問題

5.機器本身的問題

1.查看日志，沒有發現集中的錯誤日志，初步排除代碼邏輯處理錯誤。

2.首先聯系了內部下游系統觀察了他們的監控，發現一起正常。可以排除下游系統故障對我們的影響。

3.查看provider接口的調用量，對比7天沒有突增，排除業務方調用量的問題。

4.查看tcp監控，TCP狀態正常，可以排除是http請求第三方超時帶來的問題。

5.查看機器監控，6臺機器cpu都在上升，每個機器情況一樣。排除機器故障問題。

  即通過上述方法沒有直接定位到問題。

1.重啟了6臺中問題比較嚴重的5臺機器，先恢復業務。保留一臺現場，用來分析問題。

2.查看當前的tomcat線程pid

3.查看該pid下線程對應的系統占用情況。top -Hp 384

4.發現pid 4430 4431 4432 4433 線程分別占用了約40%的cpu

5.將這幾個pid轉為16進制，分別為114e 114f 1150 1151

6.下載當前的java線程棧  sudo -u tomcat jstack -l 384>/1.txt

7.查詢5中對應的線程情況，發現都是gc線程導致的

8.dump java堆數據

sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384

9.使用MAT加載堆文件，可以看到javax.crypto.JceSecurity對象占用了95%的內存空間，初步定位到問題。

MAT下載地址：http://www.eclipse.org/mat/

10.查看類的引用樹，看到BouncyCastleProvider對象持有過多。即我們代碼中對該對象的處理方式是錯誤的，定位到問題。

我們代碼中有一塊是這樣寫的

這是加解密的功能，每次運行加解密都會new一個BouncyCastleProvider對象,放倒Cipher.getInstance()方法中。

看下Cipher.getInstance()的實現，這是jdk的底層代碼實現，追蹤到JceSecurity類中

verifyingProviders每次put后都會remove,verificationResults只會put，不會remove.

看到verificationResults是一個static的map，即屬于JceSecurity類的。

所以每次運行到加解密都會向這個map put一個對象，而這個map屬于類的維度，所以不會被GC回收。這就導致了大量的new的對象不被回收。

將有問題的對象置為static，每個類持有一個，不會多次新建。

遇到線上問題不要慌，首先確認排查問題的思路：

1. 查看日志

2. 查看CPU情況

3. 查看TCP情況

4. 查看java線程，jstack

5. 查看java堆，jmap

6. 通過MAT分析堆文件，尋找無法被回收的對象

上述就是小編為大家分享的如何通過jstack與jmap分析一次線上故障了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。