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過高導致的性能問題。