JDK 自帶的 JAVA 性能分析工具 。 它已經在你的 JDK bin 目錄裡了，只要你使用的是 JDK1.6 Update7 之後的版本。點擊一下 jvisualvm.exe 圖標它就可以運行了。

這裡是 VisualVM 的官方網站： https://visualvm.dev.java.net ，資料很全，同時提供 VisualVM 最近版本下載。

1. 安裝

只要安裝 JDK 即可，運行 jvisualvm.exe ，選擇【工具】——【插件】——【可用插件】

·

2 使用

2.1.
遠程機器設置

要從遠程應用程序中檢索數據，需要在遠程 JVM 上運行 jstatd 實用程序。 即要進行以下操作：

1) 在 jdk 安裝目錄的 bin 目錄下新建文件 jstatd.all.policy ，文件內容為：  

permission java.security.AllPermission;

};

2) 再新建文件 jstatd. sh ，文件內容為：

./jstatd -J-Djava.security.policy=jstatd.all.policy

3) 啟動 jstat : nohup jstatd.sh & ( 默認啟動端口為 1099)

4) 配置 resin.conf ，把以下註釋打開：

   <!-- no use args

     <jvm-arg>-Xdebug</jvm-arg>

     <jvm-arg>-Dcom.sun.management.jmxremote</jvm-arg>

2.2. 添加遠程監控機器

2.3. 配置 Jconsole

1) 在應用的 resin 配置文件中加配置：

<jvm-arg>-Dcom.sun.management.jmxremote</jvm-arg>

<jvm-arg>-Dcom.sun.management.jmxremote.port=9009</jvm-arg>

<jvm-arg>-Dcom.sun.management.jmxremote.ssl=false</jvm-arg>

<jvm-arg>-Dcom.sun.management.jmxremote.authenticate=false</jvm-arg>

2) 選擇 Tools 菜單裡的 Plugins 菜單，點擊 'VisualVM-JConsole' 然後點擊 'Install' 按鈕

3) 安裝完畢後重新啟動 VisualVm

4) 配置 JConsole 頁簽，點擊 'JConsole Plugins' 按鈕

5) 點擊 'Add JAR/Folder' 按鈕，

6) 添加 JDK_HOME/demo/management/JTop/JTop.jar

7) 重新打開監控頁面，可以看到 JConsole 正常工作

2.4. 遠程監控 cpu 使用情況

點採樣器欄：

點擊 cpu ，觀察到 cpu 使用狀況，點擊 snapshot ，採取結果，可以選擇查看方法、類或包的 cpu 使用情況，使用 工具可以查找想要查看的方法、類或包：

2.5. GC 監控

1) 選擇要監控的 pid ，查看 GC 情況

如果 Old 區滿了，每次回收都很少或者回收不了，說明 GC 有問題 。

2.6. 遠程監控內存洩露、解決內存溢出問題

1) 內存洩露、溢出的異同

同：都會導致應用程序運行出現問題，性能下降或掛起。

異：

v 內存洩露是導致內存溢出的原因之一；內存洩露積累起來將導致內存溢出。

v 內存洩露可以通過完善代碼來避免；內存溢出可以通過調整配置來減少發生頻率，但 無法徹底避免。

2) 監測內存洩漏

· 內存 洩漏 是指程序中間動態分配了內存，但在程序結束時沒有釋放這部分內存，從而造成那部分內存不可用的情況，重啟計算機可以解決，但也有可能再次發生內存洩露，內存洩露和硬件沒有關係，它是由軟件設計缺陷引起的。  

· 內存洩漏可以分為4類：

a. 常發性內存洩漏 。發生內存洩漏的代碼會被多次執行到，每次被執行的時候都會導致一塊內存洩漏。

b. 偶發性內存洩漏 。發生內存洩漏的代碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對於特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測內存洩漏至關重要。

c. 一次性內存洩漏 。發生內存洩漏的代碼只會被執行一次，或者由於算法上的缺陷，導致總會有一塊僅且一塊內存發生洩漏。比如，在類的構造函數中分配內存，在析構函數中卻沒有釋放該內存，所以內存洩漏只會發生一次。

d. 隱式內存洩漏 。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這裡並沒有發生內存洩漏，因為最終程序釋放了所有申請的內存。但是對於一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，我們稱這類內存洩漏為隱式內存洩漏。

3) Heap dump 分析

每隔一段時間給所檢測的 java 應用做一次 heap dump ：

（或者在響應應用 pid 上鼠標右鍵 heap dump ）彈出以下提示框：

在應用服務器將此文件下載到 jvisual vm 所在的機器上， file--load 打開此文件，如下面三圖所示：

對比上面三個截圖，發現 似乎有個東西在急速飆升，仔細一看是這個對象：org.eclipse.swt.graphics.Image 在第一章圖中這個還沒排的上，第二次dump已經上升到5181個，第三次就是7845個了。漲速相當快，而且和任務管理器裡面看到的GDI數量增漲一致，就是它了 。

問題到這兒就比較清楚了，回到代碼裡面仔細一看可以發現，是某個地方反覆的用圖片來創建Image對像導致的，改掉以後搞定問題。

到這裡其實我想說的是，Java使用起來其實要比C++更容易導致內存洩漏。對於C++來說，每一個申請的對象都必須明確釋放，任何沒有釋放的對象都會導致memleak，這是不可饒恕的，而且這類問題已經有很多工具和方法來解決。但是到了Java裡面情況就不同了，對於Java程序員來說對象都是不需要也無法主動銷毀的，所以一般的思路是：隨用隨new，用完即丟。很多對像具體的生命週期可能連寫代碼的人自己也不清楚，或者不需要清楚，只知道某個時刻垃圾收集器會去做的，不用管。但很可能某個對象在 「 用完即丟 」 的時候在另一個不容易發現的地方被保存了一個引用，那麼這個對象就永遠不會被回收。更加糟糕的是整個程序從設計之初就沒有考慮過對像回收的問題，對於C++程序員來說memleak必然是一個設計錯誤，但是對Java程序員來說這只是一個疏忽，而且似乎沒有什麼好的辦法來避免。今天看到的這個問題是因為GDI洩漏會造成嚴重後果才被重視，但如果僅僅是造成內存洩漏，那這個程序可能得連續跑上個十天半個月才會發現問題。最後就是，對於c++，錯誤的代碼在測試階段就可以快速的偵測出哪怕一個byte的memleak並加以改正，但是對於java程序，理論上沒有哪個工具能夠知道是不是有洩漏，因為除了作者自己以外沒有人能夠知道一個被引用的對象是不是應該被銷毀，只有通過大量的，長期的壓力測試才能發現問題，這是很危險的一件事情。

4) 解決內存溢出問題

1、java.lang.OutOfMemoryError: PermGen space

JVM管理兩種類型的內存，堆和非堆。堆是在JVM啟動時創建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運行期內GC不會釋放空間。如果web app用了大量的第三方jar或者應用有太多的class文件而恰好MaxPermSize設置較小，超出了也會導致這塊內存的佔用過多造成溢出，或者tomcat熱部署時侯不會清理前面加載的環境，只會將context更改為新部署的，非堆存的內容就會越來越多。

PermGen space的全稱是Permanent Generation space ， 是指內存的永久保存區域，這塊內存主要是被JVM存放Class和Meta信息的 ， Class在被Loader時就會被放到PermGen space中，它和存放類實例(Instance)的Heap區域不同 ， GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的應用中有很CLASS的話 ， 就很可能出現PermGen space錯誤，這種錯誤常見在web服務器對JSP進行pre compile的時候。如果你的WEB APP下都用了大量的第三方jar, 其大小超過了jvm默認的大小(4M)那麼就會產生此錯誤信息了。

如上圖所示， PermGen 在程序運行一段時間後超出了我們指定的 128MB ，通過 Classes 視圖看到， Java 在運行的同時加載了大量的類到內存中。 PermGen 會存儲 Jar 或者
Class 的描述信息；所以在 class 大量增加的同時 PermGen 超出了我們指定的範圍。為了讓應用穩定，我們需要探尋新的 PermGen 範圍。檢測時段時候後（如下圖）發現 PermGen 在 145MB 左右穩定，那麼我們就得到了穩定的新參數；這樣 PermGen 內存溢出的問題得到解決。

2、java.lang.OutOfMemoryError: Java heap space

第一種情況是個補充，主要存在問題就是出現在這個情況中。其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。如果內存剩餘不到40％，JVM就會增大堆到Xmx設置的值，內存剩餘超過70％，JVM就會減小堆到Xms設置的值。 所以服務器的Xmx和Xms設置一般應該設置相同避免每次GC後都要調整虛擬機堆的大小
。假設物理內存無限大，那麼JVM內存的最大值跟操作系統有關，一般32位機是1.5g到3g之間，而64位的就不會有限制了。

注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來。

垃圾回收GC的角色 ， JVM調用GC的頻度還是很高的，主要兩種情況下進行垃圾回收：

一個是 當應用程序線程空閒；另一個是java內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。因為這個異常根據系統運行環境決定，所以無法預期它何時出現。

根據GC的機制，程序的運行會引起系統運行環境的變化，增加GC的觸發機會。

為了避免這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和GC的開銷。顯示調用System.GC()只能建議JVM需要在內存中對垃圾對像進行回收，但不是必須馬上回收 。 一個是並不能解決內存資源耗空的局面，另外也會增加GC的消耗。

2.7. 如何避免內存洩漏、溢出

1) 盡早釋放無用對象的引用。

好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後自動設置為null，暗示垃圾收集器來收集該對象，防止發生內存洩露。

2) 程序進行字符串處理時，盡量避免使用String，而應使用StringBuffer。

因為每一個String對象都會獨立佔用內存一塊區域，如：

1.

2.

3. String str3 = str + str2;    

4. // 假如執行此次之後str , str2再不被調用，那麼它們就會在內存中等待GC回收；    

5. // 假如程序中存在過多的類似情況就會出現內存錯誤；  

3) 盡量少用靜態變量。

因為靜態變量是全局的，GC不會回收。

4) 避免集中創建對像尤其是大對象，如果可以的話盡量使用流操作。

JVM會突然需要大量內存，這時會觸發GC優化系統內存環境； 一個案例如下：

1. // 使用jspsmartUpload作文件上傳，運行過程中經常出現java.outofMemoryError的錯誤，    

2. // 檢查之後發現問題：組件裡的代碼    

3. m_totalBytes = m_request.getContentLength();    

4. m_binArray = new byte[m_totalBytes];    

5. // totalBytes這個變量得到的數極大，導致該數組分配了很多內存空間，而且該數組不能及時釋放。    

6. // 解決辦法只能換一種更合適的辦法，至少是不會引發outofMemoryError的方式解決。    

7. // 參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747  

5) 盡量運用對像池技術以提高系統性能。

生命週期長的對象擁有生命週期短的對象時容易引發內存洩漏，例如大集合對像擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然後解決一塊釋放一塊的策略。

6) 不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。

可以適當的使用hashtable，vector 創建一組對像容器，然後從容器中去取那些對象，而不用每次new之後又丟棄。

7) 優化配置。

a. 設置-Xms、-Xmx相等；

b. 設置NewSize、MaxNewSize相等；

c. 設置Heap size, PermGen space:

本小節我們介紹一下如何使用JDK自帶的jvisualvm工具來監控本地的Java進程，該工具是一個圖形化的監控工具。

jvisualvm官方文檔地址如下：

https://visualvm.github.io/documentation.html

一、介紹

VisualVM，能夠監控線程，內存情況，查看方法的CPU時間和內存中的對 象，已被GC的對象，反向查看分配的堆棧(如100個String對象分別由哪幾個對象分配出來的).

從界面上看還是比較簡潔的，左邊是樹形結構，自動顯示當前本機所運行的Java程序，還可以添加遠程的Java VM，其中括號裏面的PID指的是進程ID。OverView界面顯示VM啟動參數以及該VM對應的一些屬性。Monitor界面則是監控Java堆大小，Permgen大小，Classes和線程數量。jdk不同版本中界面會不太一致，如有的含cpu監控，有的則不含（jdk1.6.0_10未包含）。

二、JVisualVM能做什麽

VisualVM 是Netbeans的profile子項目，已在JDK6.0 update 7 中自帶，能夠監控線程，內存情況，查看方法的CPU時間和內存中的對 象，已被GC的對象，反向查看分配的堆棧(如100個String對象分別由哪幾個對象分配出來的)。

三、jvisualvm在哪

jvisualvm位於JAVA_HOME/bin目錄下，如下圖：

直接雙擊就可以打開該程序，打開後界面如下：

如果只是監控本地的java進程，是不需要配置參數的，直接打開就能夠進行監控。首先我們需要在本地打開一個Java程序，例如我打開IDEA，這時在jvisualvm界面就可以看到與IDEA相關的Java進程了：

點擊一個進程，就可以看到該進程的概述信息，該進程的JVM參數以及系統屬性等信息都能夠查看到：

點擊 “監視” 就能夠看到CPU、內存、類以及線程的活動狀況，點擊右上角的 “堆Dump” 就能夠導出內存映像文件：

除了導出，也還可以導入內存映像文件，只不過分析功能上沒有MAT強大：

點擊 “線程” 就能夠看到該進程內部的所有線程，以及線程的運行狀況等信息。如果點擊右上角的 “線程Dump” 就會導出一個內容與jstack打印內容一致的文件：

點擊 “抽樣器” 界面中的 “CPU ” 就可以動態的看到每個方法的執行時間，當我們的代碼執行的比較慢了，就可以通過抽樣器來查看是哪一個方法執行的比較慢：

而點擊 “內存” 的話，就可以實時的、動態的查看到每個類實例對象的數量以及這些實例所占用的內存大小：

在Profiler界面上，可以對CPU、內存進行性能分析，分析後會給出分析結果：

接下來我們下載兩個比較實用的插件，首先到VisualVM插件中心，地址如下：

https://visualvm.github.io/pluginscenters.html

因為有時候自帶的插件地址可能無法使用，所以我們需要自行配置可用的地址：

回到jvisualvm中，點擊菜單欄中的 “工具“ 選項，再點擊子菜單的 ”插件“ 選項：

然後按照下圖配置插件地址：

配置好插件地址後，按照下圖勾選以下兩個插件：

按照提示一步步的進行安裝：

安裝完成：

插件安裝完成後需要重啟jvisualvm才會生效，這時會看到選項卡中多了一個 “Visual GC” 選項，點擊該選項後，可以動態的查看到JVM內存結構各個區域的運行狀況，極大方便我們進行各個區內存的監控及調優：

另一個插件的作用就是可以讓我們針對某個進程編寫BTrace腳本，右鍵點擊一個進程，在彈出來的菜單中，選擇“Trace application...”，就可以編寫BTrace腳本了：

監控遠程的java進程

在上一小節中，我們簡單介紹了如何使用JDK自帶的jvisualvm工具來監控本地的Java進程。而本小節我們將介紹一下如何使用jvisualvm來監控遠程的java進程，我們這裏以線上服務器的Tomcat為例。

打開jvisualvm，雙擊 “遠程” 選項，添加一個遠程主機，即遠程的服務器：

然後編輯Tomcat的catalina.sh文件，在該文件中加入如下配置內容：

[email protected] ~]# vim /home/tomcat/apache-tomcat-8.5.8/bin/catalina.sh
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9004 -Dcom.su
n.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
-Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname=119.23.250.83"

配置簡單說明：

• -Dcom.sun.management.jmxremote添加一個jmx遠程連接屬性
• -Dcom.sun.management.jmxremote.port=9004 指定連接的端口號
• -Dcom.sun.management.jmxremote.authenticate=false 是否啟用驗證
• -Dcom.sun.management.jmxremote.ssl=false 是否啟用ssl
• Djava.net.preferIPv4Stack=true 是否優先使用ipv4
• -Djava.rmi.server.hostname=119.23.250.83 指定遠程主機的ip地址

如下圖：

增加完配置後，重啟Tomcat，查看是否有9004端口，有的話就代表配置成功了，如下：

[email protected] ~]# netstat -lntp |grep java
tcp        0      0 0.0.0.0:9004            0.0.0.0:*               LISTEN      13399/java
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      13399/java
tcp        0      0 0.0.0.0:46199           0.0.0.0:*               LISTEN      13399/java
tcp        0      0 0.0.0.0:32859           0.0.0.0:*               LISTEN      13399/java
tcp        0      0 127.0.0.1:8005          0.0.0.0:*               LISTEN      13399/java
tcp        0      0 0.0.0.0:8009            0.0.0.0:*               LISTEN      13399/java
[[email protected] ~]#

回到jvisualvm中，添加JMX連接，配置連接地址和端口，如下：

註意，如果你使用的是阿裏雲等雲服務器的話，不僅需要配置防火墻規則來開放端口，還需要到雲服務器的安全組規則中，增加相應的端口規則，如下：

連接成功後，如下：

同樣的，可以像監控本地進程一樣，監控遠程的進程，在界面的操作上是一模一樣的。唯一不同的也就是需要添加一個遠程主機，然後到遠程的Java進程上配置一些jmx參數而已：

以上我們是以Tomcat這種服務型的進程作為一個示例，只需要去配置Tomcat的腳本文件就可以了。那麽如果我們需要監控的是自己線上跑的一個Java進程需要怎麽進行配置呢？其實也是一樣的，同樣的是使用這些參數，只不過是作為啟動參數而已，在啟動項目的時候加上即可，如下：

[email protected] ~]# nohup java -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9005 -Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname=119.23.250.83
-jar monitor_tuning-0.0.1-SNAPSHOT.jar &

成功啟動後，也是使用同樣的方式進行連接，註意端口不要弄錯了：

連接成功後也是一樣的：

然後我們就可以愉快的在本地監控遠程的Java進程了，而且還是圖形化的，免去了敲命令的煩惱。

我們來做一個堆內存溢出的實驗，看看jvisualvm能否監控到內存的變化，在瀏覽器上訪問我們之前在基於JDK命令行工具的監控一文中所編寫的/head接口。訪問後如下，可以看到堆內存的變化很激烈，利用jvisualvm工具進行監控，就很明顯的就能夠觀察到該進程的異常：

所以線上監控不能少，是我們必須要掌握的一種技能。監控相當於我們的眼睛，如果沒有監控工具，那我們就相當於瞎子一樣兩眼一抹黑。無法看到內存、線程的使用情況，當出現異常的時候，也難以定位問題發生的原因。

基於JVisualVM的可視化監控