JVisualVM初步使用

1、前言

jvm調優工具有常見的為Jconsole，jProfile，VisualVM，

• Jconsole: 為jdk自帶，功能簡單，但是可以在系統有一定負荷的情況下使用。對垃圾回收算法有很詳細的跟蹤。
• JProfiler：商業軟件，需要付費。功能強大。
• VisualVM：JDK自帶，功能強大，與JProfiler類似。其能夠監控線程，內存情況，查看方法的CPU時間和內存中的對 象，已被GC的對象，反向查看分配的堆棧等功能。

2、JVisualVM初步使用

2.1 安裝

VisualVM可以進行遠程和本地監控，在jdk安裝目錄中運行jvisualvm.exe（E:\work\Java\jdk1.8.0_321\bin ），也可以下載獨立版的visual vm（下載鏈接地址：https://github.com/oracle/visualvm/releases/download/2.1.3/visualvm_213.zip）。

2.2 插件

可以選擇安裝一些自己需要的插件，菜單欄->工具->插件，選擇需要安裝的插件

2.3 visual Gc

比如下載的visual gc插件，可以跟蹤gc的情況，分析后可以更好配置jvm參數

3、遠程連接

連接教程：https://blog.csdn.net/qq_44872773/article/details/122042495

坑點：https://blog.csdn.net/weixin_44906271/article/details/121373973

4、如何進行JVM調優

觀察內存釋放情況、集合類檢查、對象樹

上面這些調優工具都提供了強大的功能，但是總的來說一般分為以下幾類功能

4.1 堆信息查看

可查看堆空間大小分配（年輕代、年老代、持久代分配）

提供即時的垃圾回收功能

垃圾監控（長時間監控回收情況）

查看堆內類、對象信息查看：數量、類型等

對象引用情況查看

有了堆信息查看方面的功能，我們一般可以順利解決以下問題：

–年老代年輕代大小劃分是否合理

–內存泄漏

–垃圾回收算法設置是否合理

4.2 線程監控

線程信息監控：系統線程數量。

線程狀態監控：各個線程都處在什么樣的狀態下

Dump線程詳細信息：查看線程內部運行情況

死鎖檢查

熱點分析

CPU熱點：檢查系統哪些方法占用的大量CPU時間

內存熱點：檢查哪些對象在系統中數量最大（一定時間內存活對象和銷毀對象一起統計）

這兩個東西對于系統優化很有幫助。我們可以根據找到的熱點，有針對性的進行系統的瓶頸查找和進行系統優化，而不是漫無目的的進行所有代碼的優化。

快照

快照是系統運行到某一時刻的一個定格。在我們進行調優的時候，不可能用眼睛去跟蹤所有系統變化，依賴快照功能，我們就可以進行系統兩個不同運行時刻，對象（或類、線程等）的不同，以便快速找到問題

舉例說，我要檢查系統進行垃圾回收以后，是否還有該收回的對象被遺漏下來的了。那么，我可以在進行垃圾回收前后，分別進行一次堆情況的快照，然后對比兩次快照的對象情況。

4.3 內存泄漏檢查

內存泄漏是比較常見的問題，而且解決方法也比較通用，這里可以重點說一下，而線程、熱點方面的問題則是具體問題具體分析了。

內存泄漏一般可以理解為系統資源（各方面的資源，堆、棧、線程等）在錯誤使用的情況下，導致使用完畢的資源無法回收（或沒有回收），從而導致新的資源分配請求無法完成，引起系統錯誤。

內存泄漏對系統危害比較大，因為他可以直接導致系統的崩潰。

需要區別一下，內存泄漏和系統超負荷兩者是有區別的，雖然可能導致的最終結果是一樣的。內存泄漏是用完的資源沒有回收引起錯誤，而系統超負荷則是系統確實沒有那么多資源可以分配了（其他的資源都在使用）。

4.3.1 年老代堆空間被占滿

異常： java.lang.OutOfMemoryError: Java heap space

說明：

這是最典型的內存泄漏方式，簡單說就是所有堆空間都被無法回收的垃圾對象占滿，虛擬機無法再在分配新空間。

如上圖所示，這是非常典型的內存泄漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點，所有谷底部分表示是一次垃圾回收后剩余的內存。連接所有谷底的點，可以發現一條由底到高的線，這說明，隨時間的推移，系統的堆空間被不斷占滿，最終會占滿整個堆空間。因此可以初步認為系統內部可能有內存泄漏。（上面的圖僅供示例，在實際情況下收集數據的時間需要更長，比如幾個小時或者幾天）

解決：

這種方式解決起來也比較容易，一般就是根據垃圾回收前后情況對比，同時根據對象引用情況（常見的集合對象引用）分析，基本都可以找到泄漏點。

4.3.2 元空間被占滿

**異常：**java.lang.OutOfMemoryError: PermGen space

說明：

系統的代碼非常多或引用的第三方包非常多或者通過動態代碼生成類加載等方法，導致元空間的內存占用很大。

解決：

• 優化參數配置，避免影響其他JVM進程
• 慎重引用第三方包
• 關注動態生成類的框架

4.3.3 堆棧溢出

• 異常：java.lang.StackOverflowError

• 說明：這個就不多說了，一般就是遞歸沒返回，或者循環調用造成

線程堆棧滿

異常：Fatal: Stack size too small

說明：java中一個線程的空間大小是有限制的。JDK5.0以后這個值是1M。與這個線程相關的數據將會保存在其中。但是當線程空間滿了以后，將會出現上面異常。

解決：增加線程棧大小。-Xss2m。但這個配置無法解決根本問題，還要看代碼部分是否有造成泄漏的部分。

4.3.4 系統內存被占滿

異常：java.lang.OutOfMemoryError: unable to create new native thread

說明：

這個異常是由于操作系統沒有足夠的資源來產生這個線程造成的。系統創建線程時，除了要在Java堆中分配內存外，操作系統本身也需要分配資源來創建線程。因此，當線程數量大到一定程度以后，堆中或許還有空間，但是操作系統分配不出資源來了，就出現這個異常了。

分配給Java虛擬機的內存愈多，系統剩余的資源就越少，因此，當系統內存固定時，分配給Java虛擬機的內存越多，那么，系統總共能夠產生的線程也就越少，兩者成反比的關系。同時，可以通過修改-Xss來減少分配給單個線程的空間，也可以增加系統總共內生產的線程數。

解決：

重新設計系統減少線程數量。

線程數量不能減少的情況下，通過-Xss減小單個線程大小。以便能生產更多的線程。

5、jvm參數優化建議

本質上是減少GC的次數。

如果是頻繁創建對象的應用，可以適當增加新生代大小。常量較多可以增加持久代大小。對于單例較多的對象可以增加老生代大小。比如spring應用中。

GC選擇，在JDK5.0以后，JVM會根據當前系統配置進行判斷。一般執行-Server命令便可以。gc包括三種策略：串行，并行，并發。

吞吐量大大應用，一般采用并行收集，開啟多個線程，加快gc的是否。

響應速度高的應用，一般采用并發收集，比如應用服務器。

年老代建議配置為并發收集器，由于并發收集器不會壓縮和整理磁盤碎片，因此建議配置：

-XX:+UseConcMarkSweepGC #并發收集年老代

-XX:CMSInitiatingOccupancyFraction=80 # 表示年老代空間到80%時就開始執行CMS

-XX:+UseCMSCompactAtFullCollection # 打開對年老代的壓縮。可能會影響性能，但是可以消除內存碎片。

-XX:CMSFullGCsBeforeCompaction=10 # 由于并發收集器不對內存空間進行壓縮、整理，所以運行一段時間以后會產生“碎片”，使得運行效率降低。此參數設置運行次FullGC以后對內存空間進行壓縮、整理。

總結

以上是生活随笔為你收集整理的JVisualVM初步使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。