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

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

1.安裝

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

?

·

2使用

2.1.遠程機器設置

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

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

grant codebase "file:${java.home}/../lib/tools.jar" {

?

permission java.security.AllPermission;

?

};

?

2)再新建文件jstatd.sh ，文件內(nèi)容為：

./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.添加遠程監(jiān)控機器

?

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)重新打開監(jiān)控頁面，可以看到JConsole正常工作

2.4.遠程監(jiān)控cpu使用情況

點采樣器欄：

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

2.5.GC監(jiān)控

1)選擇要監(jiān)控的pid，查看GC情況

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

2.6.遠程監(jiān)控內(nèi)存泄露、解決內(nèi)存溢出問題

1)內(nèi)存泄露、溢出的異同

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

異：

v內(nèi)存泄露是導致內(nèi)存溢出的原因之一；內(nèi)存泄露積累起來將導致內(nèi)存溢出。

v內(nèi)存泄露可以通過完善代碼來避免；內(nèi)存溢出可以通過調(diào)整配置來減少發(fā)生頻率，但無法徹底避免。

2)監(jiān)測內(nèi)存泄漏

·內(nèi)存泄漏是指程序中間動態(tài)分配了內(nèi)存，但在程序結(jié)束時沒有釋放這部分內(nèi)存，從而造成那部分內(nèi)存不可用的情況，重啟計算機可以解決，但也有可能再次發(fā)生內(nèi)存泄露，內(nèi)存泄露和硬件沒有關(guān)系，它是由軟件設計缺陷引起的。 ?

·內(nèi)存泄漏可以分為4類：

a. 常發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼會被多次執(zhí)行到，每次被執(zhí)行的時候都會導致一塊內(nèi)存泄漏。

b.偶發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只有在某些特定環(huán)境或操作過程下才會發(fā)生。常發(fā)性和偶發(fā)性是相對的。對于特定的環(huán)境，偶發(fā)性的也許就變成了常發(fā)性的。所以測試環(huán)境和測試方法對檢測內(nèi)存泄漏至關(guān)重要。

c.一次性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只會被執(zhí)行一次，或者由于算法上的缺陷，導致總會有一塊僅且一塊內(nèi)存發(fā)生泄漏。比如，在類的構(gòu)造函數(shù)中分配內(nèi)存，在析構(gòu)函數(shù)中卻沒有釋放該內(nèi)存，所以內(nèi)存泄漏只會發(fā)生一次。

d.隱式內(nèi)存泄漏。程序在運行過程中不停的分配內(nèi)存，但是直到結(jié)束的時候才釋放內(nèi)存。嚴格的說這里并沒有發(fā)生內(nèi)存泄漏，因為最終程序釋放了所有申請的內(nèi)存。但是對于一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內(nèi)存也可能導致最終耗盡系統(tǒng)的所有內(nèi)存。所以，我們稱這類內(nèi)存泄漏為隱式內(nèi)存泄漏。

3)Heap dump 分析

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

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

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

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

問題到這兒就比較清楚了，回到代碼里面仔細一看可以發(fā)現(xiàn)，是某個地方反復的用圖片來創(chuàng)建Image對象導致的，改掉以后搞定問題。

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

4)解決內(nèi)存溢出問題

1、java.lang.OutOfMemoryError: PermGen space

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

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

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

?

2、java.lang.OutOfMemoryError: Java heap space

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

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

?

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

一個是當應用程序線程空閑；另一個是java內(nèi)存堆不足時，會不斷調(diào)用GC，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時，就會報out of memory錯誤。因為這個異常根據(jù)系統(tǒng)運行環(huán)境決定，所以無法預期它何時出現(xiàn)。

根據(jù)GC的機制，程序的運行會引起系統(tǒng)運行環(huán)境的變化，增加GC的觸發(fā)機會。

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

?

2.7.如何避免內(nèi)存泄漏、溢出

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

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

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

因為每一個String對象都會獨立占用內(nèi)存一塊區(qū)域，如：

1.String str = "aaa"; ? ?

2.String str2 = "bbb"; ? ?

3.String str3 = str + str2; ? ?

4.// 假如執(zhí)行此次之后str , str2再不被調(diào)用，那么它們就會在內(nèi)存中等待GC回收； ? ?

5.// 假如程序中存在過多的類似情況就會出現(xiàn)內(nèi)存錯誤； ?

3) 盡量少用靜態(tài)變量。

因為靜態(tài)變量是全局的，GC不會回收。

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

JVM會突然需要大量內(nèi)存，這時會觸發(fā)GC優(yōu)化系統(tǒng)內(nèi)存環(huán)境； 一個案例如下：

1.// 使用jspsmartUpload作文件上傳，運行過程中經(jīng)常出現(xiàn)java.outofMemoryError的錯誤， ? ?

2.// 檢查之后發(fā)現(xiàn)問題：組件里的代碼 ? ?

3.m_totalBytes = m_request.getContentLength(); ? ?

4.m_binArray = new byte[m_totalBytes]; ? ?

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

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

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

5) 盡量運用對象池技術(shù)以提高系統(tǒng)性能。

生命周期長的對象擁有生命周期短的對象時容易引發(fā)內(nèi)存泄漏，例如大集合對象擁有大數(shù)據(jù)量的業(yè)務對象的時候，可以考慮分塊進行處理，然后解決一塊釋放一塊的策略。

6) 不要在經(jīng)常調(diào)用的方法中創(chuàng)建對象，尤其是忌諱在循環(huán)中創(chuàng)建對象。

可以適當?shù)氖褂胔ashtable，vector 創(chuàng)建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄。

7) 優(yōu)化配置。

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

b.設置NewSize、MaxNewSize相等；

c.設置Heap size, PermGen space:

總結(jié)

以上是生活随笔為你收集整理的Jvisualvm--JAVA性能分析工具的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。