JVM線上故障排查的方法

本篇內容介紹了“JVM線上故障排查的方法”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

CPU 飚高  ----請使用linux運維監控命令

以下為摘抄：

思路：首先找到 CPU 飚高的那個 Java 進程，因為你的服務器會有多個 JVM 進程。然后找到那個進程中的 “問題線程”，最后根據線程堆棧信息找到問題代碼。最后對代碼進行排查。

如何操作呢？

1. 通過 top 命令找到 CPU 消耗最高的進程，并記住進程 ID。

2. 再次通過 top -Hp [進程 ID] 找到 CPU 消耗最高的線程 ID，并記住線程 ID.

3. 通過 JDK 提供的 jstack 工具 dump 線程堆棧信息到指定文件中。具體命令：jstack -l [進程 ID] >jstack.log。

4. 由于剛剛的線程 ID 是十進制的，而堆棧信息中的線程 ID 是16進制的，因此我們需要將10進制的轉換成16進制的，并用這個線程 ID 在堆棧中查找。使用 printf "%x\n" [十進制數字] ，可以將10進制轉換成16進制。

5. 通過剛剛轉換的16進制數字從堆棧信息里找到對應的線程堆棧。就可以從該堆棧中看出端倪。

從樓主的經驗來看，一般是某個業務死循環沒有出口，這種情況可以根據業務進行修復。還有 C2 編譯器執行編譯時也會搶占 CPU，什么是 C2編譯器呢？當 Java 某一段代碼執行次數超過10000次（默認）后，就會將該段代碼從解釋執行改為編譯執行，也就是編譯成機器碼以提高速度。而這個 C2編譯器就是做這個的。如何解決呢？項目上線后，可以先通過壓測工具進行預熱，這樣，等用戶真正訪問的時候，C2編譯器就不會干擾應用程序了。如果是 GC 線程導致的，那么極有可能是 Full GC ，那么就要進行 GC 的優化。

內存問題排查 ----請使用JVM性能監控工具

以下為摘抄：

說完了 CPU 的問題排查，再說說內存的排查，通常，內存的問題就是 GC 的問題，因為 Java 的內存由 GC 管理。有2種情況，一種是內存溢出了，一種是內存沒有溢出，但 GC 不健康。

內存溢出的情況可以通過加上 -XX:+HeapDumpOnOutOfMemoryError 參數，該參數作用是：在程序內存溢出時輸出 dump 文件。

有了 dump 文件，就可以通過 dump 分析工具進行分析了，比如常用的MAT，Jprofile，jvisualvm 等工具都可以分析，這些工具都能夠看出到底是哪里溢出，哪里創建了大量的對象等等信息。

第二種情況就比較復雜了。GC 的健康問題。

通常一個健康的 GC 是什么狀態呢？根據樓主的經驗，YGC 5秒一次左右，每次不超過50毫秒，FGC 最好沒有，CMS GC 一天一次左右。

而 GC 的優化有2個維度，一是頻率，二是時長。

我們看YGC，首先看頻率，如果 YGC 超過5秒一次，甚至更長，說明系統內存過大，應該縮小容量，如果頻率很高，說明 Eden 區過小，可以將 Eden 區增大，但整個新生代的容量應該在堆的 30% - 40%之間，eden，from 和 to 的比例應該在 8：1：1左右，這個比例可根據對象晉升的大小進行調整。

如果 YGC 時間過長呢？YGC 有2個過程，一個是掃描，一個是復制，通常掃描速度很快，復制速度相比而言要慢一些，如果每次都有大量對象要復制，就會將 STW 時間延長，還有一個情況就是 StringTable ，這個數據結構中存儲著 String.intern 方法返回的常連池的引用，YGC 每次都會掃描這個數據結構（HashTable），如果這個數據結構很大，且沒有經過 FGC，那么也會拉長 STW 時長，還有一種情況就是操作系統的虛擬內存，當 GC 時正巧操作系統正在交換內存，也會拉長 STW 時長。

再來看看FGC，實際上，FGC 我們只能優化頻率，無法優化時長，因為這個時長無法控制。如何優化頻率呢？

首先，FGC 的原因有幾個，1 是 Old 區內存不夠，2 是元數據區內存不夠，3 是 System.gc()， 4 是 jmap 或者 jcmd，5 是CMS Promotion failed 或者 concurrent mode failure，6 JVM 基于悲觀策略認為這次 YGC 后 Old 區無法容納晉升的對象，因此取消 YGC，提前 FGC。

通常優化的點是 Old 區內存不夠導致 FGC。如果 FGC 后還有大量對象，說明 Old 區過小，應該擴大 Old 區，如果 FGC 后效果很好，說明 Old 區存在了大量短命的對象，優化的點應該是讓這些對象在新生代就被 YGC 掉，通常的做法是增大新生代，如果有大而短命的對象，通過參數設置對象的大小，不要讓這些對象進入 Old 區，還需要檢查晉升年齡是否過小。如果 YGC 后，有大量對象因為無法進入 Survivor 區從而提前晉升，這時應該增大 Survivor 區，但不宜太大。

上面說的都是優化的思路，我們也需要一些工具知道 GC 的狀況。

JDK 提供了很多的工具，比如 jmap ，jcmd 等，oracle 官方推薦使用 jcmd 代替 jmap，因為 jcmd 確實能代替 jmap 很多功能。jmap 可以打印對象的分布信息，可以 dump 文件，注意，jmap 和 jcmd dump 文件的時候會觸發 FGC ，使用的時候注意場景。

還有一個比較常用的工具是 jstat，該工具可以查看GC 的詳細信息，比如eden ，from，to，old 等區域的內存使用情況。

還有一個工具是 jinfo，該工具可以查看當前 jvm 使用了哪些參數，并且也可以在不停機的情況下修改參數。

包括我們上面說的一些分析 dump 文件的可視化工具，MAT，Jprofile，jvisualvm 等，這些工具可以分析 jmap dump 下來的文件，看看哪個對象使用的內存較多，通常是能夠查出問題的。

還有很重要的一點就是，線上環境一定要帶上 GC 日志！！！

“JVM線上故障排查的方法”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！