Java性能調優：利用JMC分析性能

Java性能調優做爲大型分佈式系統提供高性能服務的必修課，其重要性不言而喻。

好的分析工具能起到事半功倍的效果，利用分析利器JMC、JFR，能夠實現性能問題的準肯定位。

本文主要闡述如何利用JMC分析系統性能

JMC：Java Mission Control

JFR：Java Flight Recorder

 

JMC:Java Mission Control

JMC打開性能日誌後，主要包括7部分性能報告，分別是通常信息、內存、代碼、線程、I/O、系統、事件。其中，內存、代碼、線程及I/O是系統分析的主要部分，本文會重點進行闡述。

啓動JMC後，鏈接某個本地應用後，出現以下界面：

遠程鏈接JVM（經過JMX鏈接若是想要用jmc監控遠程的JVM進程，配置方式和jvisualvm方式一同樣便可）

本地鏈接比較簡單這裏就不在贅述，遠程鏈接JVM，我在這裏利用VMWare工具進行模擬，過程當中遇到一些問題，值得注意的。

遠程機器環境： 
1. IP：192.168.91.129 
2. Java版本：SE 8u92 
3. 系統版本：openSUSE Leap 42.1 (x86_64)

首先，遠程機器被監控的程序須要開啓調試端口，在執行java命令行中加入如下屬性，屬性沒有以ssl安全認證方式鏈接的，案例中啓動監聽端口爲7091

-Dcom.sun.management.jmxremote.port=7091 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

 

而後，啓動JMC客戶端->「新建鏈接」->輸入遠程機器IP和port->點擊「完成」便可。

 

 

啓動JMC，打開生成的JFR性能日誌

1. 通常信息，以下圖所示

 

 

圖中， 堆使用量、CPU整體佔用率、GC暫停時間是很是重要的三個指標

對於Java應用而言，GC暫停時間是最值得關注的指標。

 

2. 內存信息

2.1 經過內存信息，咱們能夠清晰的看到垃圾收集器的類型，垃圾收集的暫停時間，包括最短暫停時間、平均暫停時間、最長暫停時間，以及更爲重要的垃圾收集頻率（垃圾收集的週期及STW時長）。

2.2 垃圾收集

垃圾收集的詳細報告，詳細描述了堆的回收信息，垃圾收集過程當中的異常事件，此處不一一詳述。

2.3 GC時間

詳細描述GC時間相關的信息

2.4 GC配置

詳細列出垃圾收集過程當中，GC的配置信息，主要包括年輕代、老年代的GC類型，GC過程當中的CPU狀態及GC時間比率

 

3. 代碼分析

 代碼分析是Java性能分析重點，經過代碼分析，咱們能夠清楚的知道系統運行時，哪些類及方法被高頻率的調用

3.1 熱點方法

 

經過查看熱點方法調用棧，咱們能夠清晰的瞭解到系統的主要計算資源消耗狀況。

咱們舉例說明，如上圖中的ConcurrentHashMap的containKey方法及get方法，而兩個方法都會執行計算hashcode的功能。當咱們的應用出現先判斷containKey，而後執行get方法時，咱們能夠省略containKey，這樣能夠省略一次hashcode的計算，能夠節約計算資源。

3.2 調用樹

 

經過調用樹，咱們能以模塊化的方式直觀的看到系統運行狀態。

經過上圖，咱們得知99.9%的熱點方法是運行程序，這很是符合咱們的預期，你們能夠逐層展開方法，詳細分析方法。例如：在本例中，咱們發現List與Map之間的性能差別很是大，一樣數量級的執行次數，List性能相較於Map就不好，這也符合咱們的認知範圍。

 

4. 線程

 經過線程概述報告，咱們能夠得知CPU佔用率的分佈（系統佔用率、應用程序+JVM佔用率）和活動線程數，對於CPU佔用率而言，應用程序應該佔用99%的計算資源，而活動線程數應該控制在合理範圍內（具體看應用）。

4.1 熱點線程

熱點線程一欄，詳細列出了熱點線程的數量及詳情，經過詳情，咱們能夠得知線程的執行狀況。
 4.2 線程爭用

 線程爭用是解決應用性能最爲關鍵的部分，在應用上線初期，咱們能夠經過解決線程爭用初步實現系統性能的巨大提高。上圖中的爭用爲GC致使，具體是因爲使用G1時，設置的GC預期暫停時間太短致使的。

系統性能分析初期，咱們能夠首先定位線程爭用的狀況，能夠初步達到性能的飛躍。

 

5. IO

 IO做爲系統的基礎指標，IO太高會致使系統性能急劇降低，避免過分打印日誌和生成大文件能夠避免系統IO太高致使的性能問題。