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: