轉 jvisualvm 工具使用 https://www.cnblogs.com/kongzhongqijing/articles/3625340.html

VisualVM 是Netbeans的profile子項目，已在JDK6.0 update 7 中自帶(java啓動時不須要特定參數，監控工具在bin/jvisualvm.exe)。

 

https://visualvm.dev.java.net/

 

1、介紹

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

 

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

 

官網上關於jvisualvm的用法介紹 

http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html  

 

做用：JVM和監控的應用程序運行在不一樣的服務器上，減輕應用程序的負擔，特別是HeapDump的時候，應用常可以續負擔很大。 

 

VisualVM使用簡單，幾乎0配置，功能仍是比較豐富的，幾乎囊括了其它JDK自帶命令的全部功能。

• 內存信息
• 線程信息
• Dump堆（本地進程）
• Dump線程（本地進程）
• 打開堆Dump。堆Dump能夠用jmap來生成。
• 打開線程Dump
• 生成應用快照（包含內存信息、線程信息等等）
• 性能分析。 :idea: CPU分析（各個方法調用時間，檢查哪些方法耗時多），內存分析（各種對象佔用的內存，檢查哪些類佔用內存多）
• ……

 

2、配置

 

本地監控不須要配置，只要打開某個JAVA程序就會自動的加入到本地監控中。

 

遠程監控： 本機的VisualVM就必須和遠程的JVM要進行通訊,  Visualvm目前支持兩種remote connection方式，分別是jstatd和JMX方式。

遠程監控某個中間件時，須要修改中間件的啓動文件，添加上關於jmx等的信息。

 

一、遠程監控tomcat，jmx方式。

服務器 上的 tomcat 配置 jvm 啓動參數。
在 tomcat 的 catalina.bat 中添 加以下參數: 
JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=192.168.0.237    
                      -Dcom.sun.management.jmxremote.port=18999
                      -Dcom.sun.management.jmxremote.ssl=false 
                      -Dcom.sun.management.jmxremote.authenticate=false"

上述參數未設用戶名與密碼登陸。

  客戶端VisualVM配置 (我客戶端用的是WinXP).
     a.直接反鍵點擊Remote，選擇Add Remote Host...
     b.在彈出的界面中輸入遠程機器的IP地址(192.168.0.237)，這個IP地址會加入到Remote節點下.
     c.反鍵點擊這個IP地址，選擇Add JMX Connection, 在彈出的界面中輸入剛配置的端口號(18999), 這個鏈接會加入到該IP節點下.
     d.反鍵點擊這個鏈接，選擇Open.

此處參數設置與jconsole工具遠程監控tomcat相同。

二、監視websphere服務器JVM的配置

 http://xjsunjie.blog.51cto.com/999372/1331880

jconsole & jvisualvm遠程監視websphere服務器JVM的配置案

 在啓動文件裏配置。

 

三、jstatd 配置。

 

 

3、使用

http://zhouanya.blog.51cto.com/4944792/1370017

 

visualVM 插件

https://github.com/irockel/tda

visualVM還可經過擴展增長功能。啓動頁面時有「visualVM 擴展入門指南」，若是須要哪些插件可看下這裏的介紹。

在「工具」-》「插件」-》可用插件項中列出。

 除這些可用插件外，還能夠增長第三方的插件擴展功能。

Third Party Plugins:

BTrace Plugin: support for creating, deploying and saving BTrace scripts directly from the VisualVM. Home »

Coherence Plugin: summarized statistics and information for a JMX enabled Coherence cluster. Home »

CRaSH Plugin: support for the CRaSH open source shell for the Java Platform in VisualVM. Home »

OSGi Plugin: basic management of OSGi platforms via JMX. Home »

TDA Plugin: Thread Dump Analyzer is a GUI for analyzing thread dumps generated by the Java VM. Home »

 

其餘插件裏：

 Buffer Monitor: monitoring usage of direct buffers created by ByteBuffer.allocateDirect and mapped buffers created by FileChannel.map.

 Buffer Pools和MBeans Browser能夠經過GUI的方式查看DirectMemory的即時使用狀況。

若是是JDK 7及以上版本，能夠用jconsole或者jvisualvm的MBean窗口查看java.nio.BufferPool.direct屬性。參考： https://www.zhihu.com/question/55033583

 

 

4、使用實例

一、插件「Visual GC"使用。

轉自：http://supercharles888.blog.51cto.com/609344/1179790

安裝 」Visual GC"插件:

這個插件是jvisualvm的插件，它很是強大，能夠動態的對指定的進程進行監控，而且來經過統計面板來分類顯示出各項任務/事件的總時間開銷：

安裝方法： Tool->Plugin->Available Plugins:

重啓Visual VM 以後，就能夠看到這個"Visual GC"已經被正確的顯示了。

 

實戰： 用Visual VM和Visual GC來優化咱們的Eclipse啓動：

首先，咱們啓動eclipse:

在ps -ef|grep eclipse（windows則是任務管理器）中，咱們能夠從看到這個進程id爲32561

咱們從Visual VM中找到對應的process id:

咱們切換到 「Visual GC"標籤頁，它會顯示啓動eclipse的全部測量數據：

分析：

從上圖中咱們能夠很明顯的看出來，主要的時間開銷在如下2方面：

(1)編譯時間有點長，用了3.794秒，這個時間主要是用來校驗eclipse平臺自己的字節碼了，因此咱們須要關閉字節碼校驗，讓啓動時候不會去校驗平臺自己（也是java寫的）的字節碼，爲了達到這個目的，咱們只須要在eclipse啓動參數中加上-Xverify:none

以下所示，由於咱們用的是Spring Source Tool Suite,因此咱們在STS.ini中增長這一行。

(2)另一個大問題就是類加載時間，它有2部分組成，由於類有2部分組成，一是eclipse平臺自帶的類，二是它所使用的插件的類文件，咱們能夠在eclipse啓動的時候關閉沒必要要的插件加載來減小類加載時間，方法是Preference->General->Startup and Shutdown

校驗結果：

如今咱們把eclipse關閉而且從新打開，這會啓動一個新的進程，id爲32696,咱們把此次Visual GC的測量圖和原來的進行比較：

從這裏能夠看出來，時間被明顯的縮短了，編譯時間從3.794秒縮短到2.155秒，提高百分比爲43.1%。而類加載時間從18.424秒縮短到10.208秒，提高百分比爲44.6%。

額外步驟：

對於一些其餘的啓動參數，好比初始內存，最大內存，Gem,Perm的參數。

 

二、將堆dump的文件，使用其進行查看。

1）堆dump文件。

 

2）將dump文件傳至jvisualvm本機，點擊」文件「-》」裝入「，選擇第一步生成的dump文件。

a.摘要標籤

 

可查看dump的各項信息。

文件->裝入->堆Dump－>檢查 -> 查找20保留大小最大的對象，就會觸發保留大小的計算，而後就能夠類視圖裏瀏覽，按保留大小排序了。

對象的大小有兩種統計方式：

• 自己大小(Shallow Size)：對象原本的大小。
• 保留大小(Retained Size)： 當前對象大小 + 當前對象直接或間接引用到的對象的大小總和。

看自己大小時，佔大頭的都是char[] ,byte[]之類的，沒什麼意思（用jmap -histo:live pid 看的也是自己大小）。因此須要關心的是保留大小比較大的對象，看誰在引用這些char[], byte[]。

 

b.類 標籤

 

雙擊某個類，點擊實例視圖。

c.實例試圖

 

5、遠程監控內存泄露、解決內存溢出問題

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)解決內存溢出問題

一、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內存溢出的問題獲得解決。

 

二、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的消耗。

 

如何避免內存泄漏、溢出

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

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

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

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

1.String str = "aaa";    

2.String str2 = "bbb";    

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:

 

6、使用過程當中遇到的一些問題與疑問

問題1：從服務器dump堆內存後文件比較大（3.5G左右），加載文件、查看實例對象都很慢，還提示配置xmx大小。在windows上如何配置xmx大小？

 

代表給VisualVM分配的堆內存不夠，找到${visualvm}/etc/visualvm.conf （如：C:\Program Files\Java\jdk1.6.0_10\lib\visualvm\etc）這個文件，修改

default_options=」-J-Xms24m -J-Xmx192m「

爲

default_options=」-J-Xms24m -J-Xmx1024m」（

 

再重啓VisualVM就好了。

對於「堆 dump」來講，在遠程監控jvm的時候，VisualVM是沒有這個功能的，只有本地監控的時候纔有。另外，就算是本地監控，它在dump和獲得實例的 速度那是至關的慢的。因此鑑於這幾個緣由，不建議用VisualVM，而是用jmap加上Mat來分析內存狀況。

 

問題2：

 

 

參考資料：

一、http://www.kankanews.com/ICkengine/archives/106440.shtml

二、http://freewind.me/blog/20111023/479.html

三、http://supercharles888.blog.51cto.com/609344/1179790

四、http://zhouanya.blog.51cto.com/4944792/1370017