閱讀79 返回首頁    go 魔獸

深入淺出JProfiler

該文章來自阿裏巴巴技術協會（ATA）

由於最近工作的原因，使用了JProfiler(8)來做性能瓶頸分析，發現這個工具使用起來確實挺方便，現在整理一下JProfiler相關知識(在google查了一通，沒有我想要的)。

一.JProfiler是什麼

JProfiler是由ej-technologies GmbH公司開發的一款性能瓶頸分析工具(該公司還開發部署工具)。
其特點:

  • 使用方便
  • 界麵操作友好
  • 對被分析的應用影響小
  • CPU,Thread,Memory分析功能尤其強大
  • 支持對jdbc,noSql, jsp, servlet, socket等進行分析
  • 支持多種模式(離線，在線)的分析
  • 跨平台 _2014_10_06_7_54_34_PM (圖1)

二.數據采集

Q1. JProfiler既然是一款性能瓶頸分析工具，這些分析的相關數據來自於哪裏？
Q2. JProfiler是怎麼將這些數據收集並展現的?

_2014_10_06_3_09_15_PM
(圖2)

A1. 分析的數據主要來自於下麵倆部分
1. 一部分來自於jvm的分析接口**JVMTI**(JVM Tool Interface) , JDK必須>=1.6

JVMTI is an event-based system. The profiling agent library can register handler functions for different events. It can then enable or disable selected events

例如: 對象的生命周期，thread的生命周期等信息
2. 一部分來自於instruments classes(可理解為class的重寫,增加JProfiler相關統計功能)
例如：方法執行時間，次數，方法棧等信息

A2. 數據收集的原理如圖2
1. 用戶在JProfiler GUI中下達監控的指令(一般就是點擊某個按鈕)
2. JProfiler GUI JVM 通過socket(默認端口8849)，發送指令給被分析的jvm中的JProfile Agent。
3. JProfiler Agent(如果不清楚Agent請看文章第三部分"啟動模式") 收到指令後，將該指令轉換成相關需要監聽的事件或者指令,來注冊到JVMTI上或者直接讓JVMTI去執行某功能(例如dump jvm內存)
4. JVMTI 根據注冊的事件，來收集當前jvm的相關信息。 例如: 線程的生命周期; jvm的生命周期;classes的生命周期;對象實例的生命周期;堆內存的實時信息等等
5. JProfiler Agent將采集好的信息保存到**內存**中，按照一定規則統計好(如果發送所有數據JProfiler GUI，會對被分析的應用網絡產生比較大的影響)
6. 返回給JProfiler GUI Socket.
7. JProfiler GUI Socket 將收到的信息返回 JProfiler GUI Render
8. JProfiler GUI Render 渲染成最終的展示效果

三. 數據采集方式和啟動模式

A1. JProfier采集方式分為兩種：Sampling(樣本采集)和Instrumentation

  • Sampling: 類似於樣本統計, 每隔一定時間(5ms)將每個線程棧中方法棧中的信息統計出來。優點是對應用影響小(即使你不配置任何Filter, Filter可參考文章第四部分)，缺點是一些數據/特性不能提供(例如:方法的調用次數)

  • Instrumentation: 在class加載之前，JProfier把相關功能代碼寫入到需要分析的class中，對正在運行的jvm有一定影響。優點: 功能強大，但如果需要分析的class多，那麼對應用影響較大，一般配合Filter一起使用。所以一般JRE class和framework的class是在Filter中通常會過濾掉。

注: JProfiler本身沒有指出數據的采集類型，這裏的采集類型是針對方法調用的采集類型 。因為JProfiler的絕大多數核心功能都依賴方法調用采集的數據, 所以可以直接認為是JProfiler的數據采集類型。

A2: 啟動模式:

  • Attach mode
    可直接將本機正在運行的jvm加載JProfiler Agent. 優點是很方便，缺點是一些特性不能支持。如果選擇Instrumentation數據采集方式，那麼需要花一些額外時間來重寫需要分析的class。

  • Profile at startup
    在被分析的jvm啟動時，將指定的JProfiler Agent手動加載到該jvm。JProfiler GUI 將收集信息類型和策略等配置信息通過socket發送給JProfiler Agent，收到這些信息後該jvm才會啟動。
    在被分析的jvm 的啟動參數增加下麵內容：
    語法: -agentpath:[path to jprofilerti library]
    【注】: 語法不清楚沒關係，JProfiler提供了幫助向導.
    _2014_10_06_4_15_42_PM
    (圖3)

  • Prepare for profiling:
    和Profile at startup的主要區別：被分析的jvm不需要收到JProfiler GUI 的相關配置信息就可以啟動。

  • Offline profiling
    一般用於適用於不能直接調試線上的場景。Offline profiling需要將信息采集內容和策略(一些Trigger, Trigger請參考文章第五部分)打包成一個配置文件(config.xml)，在線上啟動該jvm 加載 JProfiler Agent時，加載該xml。那麼JProfiler Agent會根據Trigger的類型會生成不同的信息。例如: heap dump; thread dump; method call record等
    語法:
    -agentpath:/home/2080/jprofiler8/bin/linux-x64/libjprofilerti.so=offline,id=151,config=/home/2080/config.xml
    【注】: config.xml中的每一個被分析的jvm的采集信息都有一個id來標識。
    下麵是使用了離線模式，並使用了每隔一秒dump heap 的Trigger：
    _2014_10_06_9_07_56_PM

四. JProfiler核心概念

  1. Filter: 什麼class需要被分析。分為包含和不包含兩種類型的Filter。
    _2014_10_06_4_32_15_PM
    (圖4)

  2. Profiling Settings: 收據收集的策略:Sampling和 Instrumentation，一些數據采集細節可以自定義.
    _2014_10_06_4_34_28_PM
    (圖5)

  3. Triggers: 一般用於**offline**模式，告知JProfiler Agent 什麼時候觸發什麼行為來收集指定信息.
    _2014_10_06_4_37_47_PM
    (圖6)

  4. Live memory: class/class instance的相關信息。 例如對象的個數，大小，對象創建的方法執行棧，對象創建的熱點。
    _2014_10_06_4_56_09_PM
    (圖7)

  5. Heap walker: 對一定時間內收集的內存對像信息進行靜態分析，功能強大且使用。包含對象的outgoing reference, incoming reference, biggest object等
    _2014_10_06_4_55_39_PM
    (圖8)

  6. CPU views: CPU消耗的分布及時間(cpu時間或者運行時間); 方法的執行圖; 方法的執行統計(最大，最小，平均運行時間等)
    _2014_10_06_4_54_48_PM
    (圖9)

  7. Thread: 當前jvm所有線程的運行狀態，線程持有鎖的狀態，可dump線程。
    _2014_10_06_4_54_07_PM
    (圖10)

  8. Monitors & locks: 所有線程持有鎖的情況以及鎖的信息
    _2014_10_06_4_59_15_PM
    (圖11)

  9. Telemetries: 包含heap, thread, gc, class等的趨勢圖(遙測視圖)

五. 實踐

為了方便實踐，直接以JProfiler8自帶的一個例子來幫助理解上麵的相關概念。
JProfiler 自帶的例子如下：模擬了內存泄露和線程阻塞的場景：
具體源碼參考: /jprofiler install path/demo/bezier

_2014_10_06_5_06_49_PM
(圖12 )

_2014_10_06_5_09_43_PM
(圖13 Leak Memory 模擬內存泄露, Simulate blocking 模擬線程間鎖的阻塞)

A1. 首先來分析下內存泄露的場景:(勾選圖13中 Leak Memory 模擬內存泄露)
1. 在**Telemetries-> Memory**視圖中你會看到大致如下圖的場景(在看的過程中可以間隔一段時間去執行Run GC這個功能)：看到下圖藍色區域,老生代在gc後(**波穀**)內存的大小在慢慢的增加(理想情況下，這個值應該是穩定的)
_2014_10_06_5_18_56_PM
(圖14)

  1. 在 Live memory->Recorded Objects 中點擊**record allocation data**按鈕，開始統計一段時間內創建的對象信息。執行一次**Run GC**後看看當前對象信息的大小，並點擊工具欄中**Mark Current**按鈕(其實就是給當前對象數量打個標記。執行一次Run GC，然後再繼續觀察;執行一次Run GC，然後再繼續觀察...。最後看看哪些對象在不斷GC後，數量還一直上漲的。最後你看到的信息可能和下圖類似
    _2014_10_06_5_26_41_PM
    (圖15 綠色是標記前的數量，紅色是標記後的增量)

  2. 在Heap walker中分析剛才記錄的對象信息
    _2014_10_06_5_28_00_PM
    (圖16)
    _2014_10_06_5_29_11_PM
    (圖17)

  3. 點擊上圖中實例最多的class，右鍵**Use Selected Instances->Reference->Incoming Reference**.
    發現該Long數據最終是存放在**bezier.BeaierAnim.leakMap**中。
    _2014_10_06_5_31_54_PM
    (圖18)

在Allocations tab項中，右鍵點擊其中的某個方法，可查看到具體的源碼信息.
_2014_10_06_5_36_08_PM
(圖19)

【注】:到這裏問題已經非常清楚了，明白了在圖17中為什麼哪些實例的數量是一樣多，並且為什麼內存在fullgc後還是回收不了(一個old 區的對象leakMap，put的信息也會進入old區, leakMap如回收不掉，那麼該map中包含的對象也回收不掉)。

A2. 模擬線程阻塞的場景(勾選圖13中Simulate blocking 模擬線程間鎖的阻塞)
為了方便區分線程，我將Demo中的BezierAnim.java的L236的線程命名為test

public void start() {
            thread = new Thread(this, "test");
            thread.setPriority(Thread.MIN_PRIORITY);
            thread.start();
        }

正常情況下，如下圖
_2014_10_06_5_50_25_PM
(圖20)

勾選了Demo中"Simulate blocking"選項後，如下圖(注意看下下圖中的狀態圖標), test線程block狀態明顯增加了。
_2014_10_06_5_53_19_PM
(圖21)

在**Monitors & locks->Monitor History**觀察了一段時間後，會發現有4種發生鎖的情況。

第一種:
AWT-EventQueue-0 線程持有一個Object的鎖，並且處於Waiting狀態。

圖下方的代碼提示出Demo.block方法調用了object.wait方法。這個還是比較容易理解的。 
_2014_10_06_6_15_59_PM
(圖22)

第二種:
AWT-EventQueue-0占有了bezier.BezierAnim$Demo實例上的鎖，而test線程等待該線程釋放。

注意下圖中下方的源代碼, 這種鎖的出現原因是Demo的blcok方法在AWT和test線程
都會被執行，並且該方法是synchronized.
_2014_10_06_6_11_20_PM
(圖23)

第三種和第四種:
test線程中會不斷向事件Event Dispatching Thread提交任務，導致競爭java.awt.EventQueue對象鎖。
提交任務的方式是下麵的代碼:repaint()和EventQueue.invokeLater

        public void run() {
            Thread me = Thread.currentThread();
            while (thread == me) {
                repaint();
                if (block) {
                    block(false);
                }
                try {
                    Thread.sleep(10);
                } catch (Exception e) {
                    break;
                }
                EventQueue.invokeLater(new Runnable() {
                    @Override
                    public void run() {
                        onEDTMethod();
                    }
                });
            }
            thread = null;
        }

_2014_10_06_6_20_05_PM
(圖24)

六. 最佳實踐

  1. JProfiler都會對一些特殊操作給予提示，這時候最好仔細閱讀下說明.
  2. "Mark Current"功能在某些場景很有效
  3. Heap walker一般是靜態分析在Live memory->Recorder objects的對象信息，這些信息可能會被GC回收掉，導致Heap walker中什麼也沒有顯示出來。這種現象是正常的。
  4. 可以才工具欄中Start Recordings配置一次性收集的信息
  5. Filter中include和exclude是有順序的，注意使用下圖**左下方**的**“Show Filter Tree”**來驗證一下順序 _2014_10_17_3_41_18_PM (圖25)

七. 參考文獻

  1. JProfiler helper: https://resources.ej-technologies.com/jprofiler/help/doc/index.html

  2. JVMTI: https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html

    如果上麵的描述有錯誤或者不清晰的地方，歡迎斧正。
    另外補充一句:JProfiler是收費的

https://oss.aliyuncs.com/yqfiles/84ff55814581391bb8f4248ca9d9264e.ppt

最後更新：2017-04-01 13:44:32

  上一篇：go 3D觸控簡介：建立數字刻度應用及快速活動欄
  下一篇：go 普通程序員通向架構師的最佳路徑？