深入了解JVM虛拟機12：JVM性能管理神器VisualVM介紹與實戰

Java虛拟機性能管理神器 - VisualVM（1）   簡介 - JVM輕量級監控分析神器

一、VisualVM是什麼？

    VisualVM是一款免費的JAVA虛拟機圖形化監控分析工具。

    1.  擁有圖形化的監控界面。

    2. 提供本地、遠端的JVM監控分析功能。

    3. 是一款免費的JAVA工具。

    4. VisualVM擁有豐富的插件支援。

二、如何擷取VisualVM？

    VisualVM官方網站：http://visualvm.java.net/

    VisualVM各版本下載下傳頁面: http://visualvm.java.net/releases.html

     下載下傳VisualVM時也應該注意，不同的JDK版本對應不同版本的VisualVM，具體根據安裝的JDK版本來下載下傳第一的VisualVM。

三、擷取那個版本？

       下載下傳版本參考：Java虛拟機性能管理神器 - VisualVM（4） - JDK版本與VisualVM版本對應關系

備注：下清單中顯示1.3.6版本隻适合JDK7和JDK8，可是我用1.3.6版還是可以監控JDK1.6_45的版本。

四、VisualVM能做什麼？

1. 顯示JAVA應用程式配置和運作時環境。

顯示JAVA應用程式JVM參數，系統屬性，JVM的資訊和運作環境。

2. 顯示本地和遠端JAVA應用程式運作狀态。

可以連接配接到遠端伺服器上運作的JAVA應用程式，監控應用程式的運作狀态。

3. 監控應用程式的性能消耗。

可以監控到應用程式熱點方法的執行單次時間、總耗時、耗時占比。

4. 顯示應用程式記憶體配置設定，顯示分析堆資訊。

顯示應用程式在運作時的編譯時間、加載時間、垃圾回收時間、記憶體區域的回收狀态等。

5. 監控應用程式線程狀态和生命周期。

監控應用程式線程的運作、休眠、等待、鎖定狀态。

6. 顯示、分析線程堆資訊。

顯示線程目前運作狀态和關聯類資訊。

7. 支援第三方插件來分析JAVA應用程式。

另外還提供更多更強大、友善的第三方插件。

Java虛拟機性能管理神器 - VisualVM（2）  監控遠端主機上的JAVA應用程式

    使用VisualVM監控遠端主機上JAVA應用程式時，需要開啟遠端主機上的遠端監控通路，或者在遠端JAVA應用程式啟動時，開啟遠端監控選項，兩種方法，選擇其中一種就可以開啟遠端監控功能，配置完成後就可以在本地對遠端主機上的JAVA應用程式進行監控。

1.遠端伺服器、應用程式配置

        1.1配合jstatd工具提供監控資料  

        1.1.1建立安全通路檔案

        在JAVA_HOME/bin目錄中，建立名稱為jstatdAllPolicy檔案（這個檔案名稱也可以順便起，不過要與jstatd啟動時指定名稱相同），将以下内容拷貝到檔案中。并保證檔案的權限和使用者都正确。

        grant codebase"file:${java.home}/../lib/tools.jar"{ permission java.security.AllPermission; };

1.1.2啟動jstatd服務

        在JAVA_HOME/bin目錄中，執行以下指令：

         ./jstatd -J-Djava.security.policy=jstatdAllPolicy-p 1099 -J-Djava.rmi.server.hostname=192.168.xxx.xxx

        jstatd指令描述以及參數說明：

           jstatd是一個基于RMI（Remove Method Invocation）的服務程式，它用于監控基于HotSpot的JVM中資源的建立及銷毀，并且提供了一個遠端接口允許遠端的監控工具連接配接到本地的JVM執行指令。

        -J-Djava.security.policy=jstatdAllPolicy 指定安全政策檔案名稱

         -p 1099  指定啟動端口

         -J-Djava.rmi.server.hostname=192.168.xxx.xxx  指定本機IP位址，在hosts檔案配置不正常時使用，最好加上。

1.2JVM啟動時配置遠端監控選項

        在需要遠端監控的JVM啟動時，開啟遠端監控選項

        -Dcom.sun.management.jmxremote.port=1099

        -Dcom.sun.management.jmxremote.ssl=false

        -Dcom.sun.management.jmxremote.authenticate=false

        -Djava.rmi.server.hostname=192.168.xxx.xxx

2.本地VisualVM配置

        在本地VisualVM的應用程式視窗，右鍵單擊【遠端】》【添加遠端主機】》【主機名】中輸入遠端主機的IP位址，點選【進階設定】輸入遠端主機開啟的監控端口，點選【确定】完成配置。

        如果一切正常，就可以看到遠端主機上的JAVA應用程式了。

Java虛拟機性能管理神器 - VisualVM（3）  排查JAVA應用程式記憶體洩漏

1. 發現問題

    線上應用部署完成後，運作1~2天左右就會出現假死，或者某天早上8~10點高峰期間突然不處理資料了。由于在測試環境的壓力測試沒有做完全，也沒有遇到相關問題。情況出現後對客戶的使用造成很大影響，上司要求趕緊排查出問題原因！

2. 排查原因

        排查原因前，與運維溝通，了解線上伺服器的運作狀态，通過ganglila觀察網絡、CPU、記憶體、磁盤的運作曆史狀态，發現程式故障前，都有一波很高的負載，排查線上日志，負載來源在8~9點平台接入資料量成倍增加，通過與産品和市場人員分析，此時段是使用者集中上班、接入平台的高峰時段，通路日志也顯示，業務場景正常，無網絡攻擊和安全問題。屬于産品業務正常的場景。

        排除了網絡安全因素後，就從程式的運作内部進行排查，首先想到的擷取JVM的dmp檔案。擷取JVM的dmp檔案有兩中方式：

        1. JVM啟動時增加兩個參數，出現 OOME 時生成堆 dump: 

                -XX:+HeapDumpOnOutOfMemoryError

                生成堆檔案位址：

                -XX:HeapDumpPath=/home/test/jvmlogs/ 

        2. 發現程式異常前通過執行指令，直接生成目前JVM的dmp檔案，15434是指JVM的程序号

                jmap -dump:format=b,file=serviceDump.dat    15434 

        由于第一種方式是一種事後方式，需要等待目前JVM出現問題後才能生成dmp檔案，實時性不高，第二種方式在執行時，JVM是暫停服務的，是以對線上的運作會産生影響。是以建議第一種方式。

3. 解決方案

        擷取到dmp檔案後，就開始進行分析。将伺服器上的dmp檔案拷貝到本地，然後啟動本地的VisualVM,點選菜單欄【檔案】選項，裝入dmp檔案

        打開dmp檔案後，檢視類标簽，就能看到占用記憶體的一個排行。

        然後通過檢查中查找最大的對象，排查到具體線程和對象。

        上列中的com.ctfo.trackservice.handler.TrackHandleThread#4就是重點排查對象。

        通過代碼的比對，在此線程中，有調用DAO接口，負責将資料存儲到資料庫中。而存儲到資料庫中時，由于存儲速度較慢，導緻此線程中的資料隊列滿了，資料積壓，無法回收導緻了隊列鎖定，結果就是程式假死，不處理資料。

        通過進一步分析，發現資料庫存儲時有瓶頸，雖然目前是批量送出，速度也不快。平均8000/秒的存儲速度。而資料庫有一個DG（備份）節點，采用的是同步備份方式，即主庫事務要等DG的事務也完成後才能傳回成功，這樣就會因為網絡因素、DG性能因素等原因導緻性能下降。通過與DBA、産品、溝通，将同步備份改為異步備份，實時同步改為異步（異步可能會導緻主備有10分鐘以内的資料延遲）。速度達到30000/秒。問題解決。

        至此，通過VisualVM分析java程式記憶體洩漏到此結束。不過還有幾個問題:1. 如果dmp檔案較大，VisualVM分析時間可能很久；另外，VisualVM對堆的分析顯示功能還不算全面。如果需要更全面的顯示，就可以使用另外一個專業的dmp檔案分析工具【Memory Analyzer (MAT)】，此工具可以作為eclipse的插件進行安裝，也可以單獨下載下傳使用。如果有感興趣的朋友，我個人建議還是單獨下載下傳使用。下載下傳位址：http://www.eclipse.org/mat/   

Java虛拟機性能管理神器 - VisualVM（4） 查找JAVA應用程式耗時的方法函數

1.為什麼要監控？

        JAVA程式在開發前，根據設計文檔的性能需求，是要對程式的性能名額進行測試的。比如接口每秒響應次數要求1000次/秒，就需要平均每次請求處理的時間在1ms以内，如果需要滿足這個名額，就需要在開發階段對接口執行函數進行監控，也可以通過列印日志進行監控，進而統計對應的性能名額，然後可以根據性能名額的要求進行相應優化。

2. 那些方法函數需要監控？

        根據具體業務的場景和需求，主要集中在IO通訊、檔案讀寫、資料庫操作、業務邏輯處理上，這些都是制約性能的重要因素，是以需要重點關注。

3. 如何排查

        在研發環境，大部分會使用syso的方式或者日志方式列印性能損耗，如果代碼沒有加在運作時才想起來，或者想關注突然想起的函數，換做以前，是需要重新開機服務的，如果有VisualVM就可以直接檢視耗時以及調用次數等情況。而不用列印、輸出日志來檢視性能損耗。

4. 如何處理

        對于性能損耗的函數，根據業務邏輯可以進行相應的優化，例如字元串處理、檔案讀寫方式、SQL語句優化、多線程處理等等方式。

       由于性能優化涉及的内容很多，這裡就不深入了。主要是告訴大家通過VisualVM來排查問題的具體位置。

Java虛拟機性能管理神器 - VisualVM（5） 排查JAVA應用程式線程鎖

1. JAVA應用程式線程鎖原因

        JAVA線程鎖的例子和原因網上一大堆，我也不在這裡深入說明，這裡主要是否講如何使用VisualVM進行排查。至于例子可以看這裡：http://blog.csdn.net/fengzhe0411/article/details/6953370 

這個例子比較極端，一般情況下，出現鎖競争激烈是比較常見的。

2. 排查JAVA應用程式線程鎖

       啟動 VisualVM，在應用程式視窗，選擇對應的JAVA應用，在詳情視窗》線程标簽（勾選線程可視化），檢視線程生命周期狀态，主要留意線程生命周期中紅色部分。

（1）綠色：代表運作狀态。一般屬于正常情況。如果是多線程環境，生産者消費者模式下，消費者一直處于運作狀态，說明消費者處理性能低，跟不上生産者的節奏，需要優化對應的代碼，如果不處理，就可能導緻消費者隊列阻塞的現象。對應線程的【RUNNABLE】狀态。

（2）藍色：代表線程休眠。線程中調用Thread.sleep()函數的線程狀态時，就是藍色。對應線程的【TIMED_WAITING】狀态。

（3）黃色：代表線程等待。調用線程的wait()函數就會出現黃色狀态。對應線程的【WAITING】狀态。

（4）紅色：代碼線程鎖定。對應線程的【BLOCKED】狀态。

3. 分析解決JAVA應用程式線程鎖

        發生線程鎖的原因有很多，我所遇到比較多的情況是多線程同時通路同一資源，且此資源使用synchronized關鍵字，導緻一個線程要等另外一個線程使用完資源後才能運作。例如再沒有連接配接池的情況下，同時通路資料庫接口。這種情況會導緻性能的極具下降，解決的方案是增加連接配接池，或者修改通路方式。或者将資源粒度細化，類似ConCurrentHashMap中的處理方式，将資源分為多個更小粒度的資源，在更小粒度資源上來處理鎖，就可以解決資源競争激烈的問題。]

微信公衆号

個人公衆号：程式員黃小斜

微信公衆号【程式員黃小斜】新生代青年聚集地，程式員成長充電站。作者黃小斜，職業是阿裡程式員，身份是斜杠青年，希望和更多的程式員交朋友，一起進步和成長！專注于分享技術、面試、職場等成長幹貨，這一次，我們一起出發。

關注公衆号後回複“2020”領取我這兩年整理的學習資料，涵蓋自學程式設計、求職面試、算法刷題、Java技術學習、計算機基礎和考研等8000G資料合集。

技術公衆号：Java技術江湖

微信公衆号【Java技術江湖】一位阿裡 Java 工程師的技術小站，專注于 Java 相關技術：SSM、SpringBoot、MySQL、分布式、中間件、叢集、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術幹貨和學習經驗，緻力于Java全棧開發！

關注公衆号後回複“PDF”即可領取200+頁的《Java工程師面試指南》強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點。