IntelliJ IDEA集成JProfiler,入門教程


說明:

JProfiler是用於分析J2EE軟件性能瓶頸並能准確定位到Java類或者方法有效解決性能問題的主流工具,它通常需要與性能測試工具如:LoadRunner配合使用,因為往往只有當系統處於壓力狀態下才能反映出性能問題。

安裝

jProfiler下載地址 http://www.ej-technologies.com/download/jprofiler/files

本地安裝

idea集成插件

安裝

啟動

首次啟動需要選擇jProfiler的安裝位置

JProfiler被啟動

功能:

2.1. 內存視圖memory views

 JProfiler的內存視圖部分可以提供動態的內存使用狀況更新視圖和顯示關於內存分配狀況信息的視圖。所有的視圖都有幾個聚集層並且能夠顯示現有存在的對象和作為垃圾回收的對象。

  •  所有對象 All Objects

顯示類或在狀況統計和尺碼信息堆上所有對象的包。你可以標記當前值並顯示差異值。

  • 記錄對象 Record Objects

顯示類或所有已記錄對象的包。你可以標記出當前值並且顯示差異值。

  • 分配訪問樹 Allocation Call Tree

顯示一棵請求樹或者方法、類、包或對已選擇類有帶注釋的分配信息的J2EE組件。

  • 分配熱點 Allocation Hot Spots

顯示一個列表,包括方法、類、包或分配已選類的J2EE組件。你可以標注當前值並且顯示差異值。對於每個熱點都可以顯示它的跟蹤記錄樹。

  • 類追蹤器 Class Tracker

類跟蹤視圖可以包含任意數量的圖表,顯示選定的類和包的實例與時間。

2.2. 堆遍歷 heap walker

在JProfiler的堆遍歷器(Heap Walker)中,你可以對堆的狀況進行快照並且可以通過選擇步驟下尋找感興趣的對象。堆遍歷器有五個視圖.

  • 類 Classes :

顯示所有類和它們的實例,可以右擊具體的類"Used Selected Instance"實現進一步跟蹤。

  • 分配 Allocations

為所有記錄對象顯示分配樹和分配熱點。

  • 索引 References

為單個對象和“顯示到垃圾回收根目錄的路徑”提供索引圖的顯示功能。還能提供合並輸入視圖和輸出視圖的功能。

  • 時間 Time

顯示一個對已記錄對象的解決時間的柱狀圖。

  • 檢查 Inspections

顯示了一個數量的操作,將分析當前對象集在某種條件下的子集,實質是一個篩選的過程。

  • 圖表 Graph

你需要在references視圖和biggest視圖手動添加對象到圖表,它可以顯示對象的傳入和傳出引用,能方便的找到垃圾收集器根源。

Ps:在工具欄點擊"Go To Start"可以使堆內存重新計數,也就是回到初始狀態。

2.3. cpu視圖 cpu views

JProfiler 提供不同的方法來記錄訪問樹以優化性能和細節。線程或者線程組以及線程狀況可以被所有的視圖選擇。所有的視圖都可以聚集到方法、類、包或J2EE組件等不同層上。

  • 訪問樹 Call Tree

顯示一個積累的自頂向下的樹,樹中包含所有在JVM中已記錄的訪問隊列。JDBC,JMS和JNDI服務請求都被注釋在請求樹中。請求樹可以根據Servlet和JSP對URL的不同需要進行拆分。

  • 熱點 Hot Spots

顯示消耗時間最多的方法的列表。對每個熱點都能夠顯示回溯樹。該熱點可以按照方法請求,JDBC,JMS和JNDI服務請求以及按照URL請求來進行計算。

  • 訪問圖 Call Graph

顯示一個從已選方法、類、包或J2EE組件開始的訪問隊列的圖。

  • 方法統計 Method Statistis

顯示一段時間內記錄的方法的調用時間細節。

2.4. 線程視圖thread views

JProfiler通過對線程歷史的監控判斷其運行狀態,並監控是否有線程阻塞產生,還能將一個線程所管理的方法以樹狀形式呈現。對線程剖析。

  • 線程歷史 Thread History

顯示一個與線程活動和線程狀態在一起的活動時間表。

  • 線程監控 Thread Monitor

顯示一個列表,包括所有的活動線程以及它們目前的活動狀況。

  • 線程轉儲 Thread Dumps

顯示所有線程的堆棧跟蹤。

2.5. 監控器視圖monitor views

  • 當前鎖定圖表 Current Locking Graph :顯示JVM中的當前鎖定情況。
  • 當前監視器 Current Monitors :顯示當前正在等待或阻塞中的線程操作。
  • 鎖定歷史圖表 Locking History Graph :顯示記錄在JVM中的鎖定歷史。
  • 監控器歷史 Monitor History :顯示等待或者阻塞的歷史。
  • 監控器使用統計 Monitor Usage Statistics :計算統計監控器監控的數據。

2.6. vm遙感勘測技術視圖VM telemetry views

  • 內存 Memory :顯示堆棧的使用狀況和堆棧尺寸大小活動時間表。
  • 記錄的對象 Recorded Objects :顯示一張關於活動對象與數組的圖表的活動時間表。
  • 記錄的生產量 Recorded Throughput :

顯示一段時間累計的JVM生產和釋放的活動時間表。

  • 垃圾回收活動 GC Activity:顯示一張關於垃圾回收活動的活動時間表。
  • 類 Classes :顯示一個與已裝載類的圖表的活動時間表。
  • 線程 Threads :顯示一個與動態線程圖表的活動時間表。
  • CPU負載 CPU Load :顯示一段時間中CPU的負載圖表。。

 

例子:

分析內存

 系統的內存消耗過多往往有以下幾種原因:

  1. 頻繁創建Java對象,如:數據庫查詢時,沒分頁,導致查出表中所有記錄;
  2. 存在大對象,如:讀取文件時,不是邊讀邊寫而是先讀到一個byte數組,這樣如果讀取的文件時50M則僅此一項操作就會占有JVM50M內存。
  3. 存在內存泄漏,導致已不被使用的對象不被GC回收,從而隨着系統使用時間的增長,內存不斷受到解壓,最終OutOfMemory。

 解決問題1和2,需借助 Live Memory 視圖,如下:

表格的三列是解決問題的關鍵,可以通過如下步驟分析:

  1. 通過單擊Size列列名可排列出最占內存的對象,查看所占內存大小,如果過大並且它對應的Instance Count比較小則說明該對象是大對象,這時可以對應Name列指示的Java類路徑找到項目里的Java類進行分析,如果不合理則改之。
  2. 通過單擊Instance Count列列名可排列出內存中實例數最多的Java對象,通過Name列指示的Java類路徑逐一排查可能存在的設計問題。

注:在JProfiler的下方可以通過包路徑過濾需要關注的對象

注意:在該視圖下方的Recorded Objects子視圖可以記錄對象,從而查看類在一段時間里的總共實例數、GC數和活動數,但是在使用這些功能時會導致系統的性能嚴重降低,例如:沒開此功能時,1000並發響應時間為1s,開此功能后500並發時響應時間才能達到1s,因此只有當存在內存泄漏時才開啟該功能。Recorded Objects子視圖記錄功能沒開啟前的截圖如下:

 

 解決問題3說明的內存溢出問題,需要同時借助Memory和Telemetry視圖。

在VM Telemetry Views試圖里,可以看出JVM的總共內存分配大小、內存占用大小和內存空閑大小以及GC后內存占用的變化。在圖4中可以看出藍色區域上線有一個陡降的坡度,這時GC后內存占用下降的結果,在分析是否存在內存泄漏問題時,該下坡具有重要意義,在用LoadRunner疲勞測試時,在穩壓期間,良好的系統內存占用應該是比較穩定,並且GC后下坡的幅度也應該比較一致,比如:前次GC釋放200M,下次GC大致也是200M,這是一般規律,具體在分析時或有不同,性能分析人員應靈活運用。

當發現GC后回收的力度越來越小,則說明很有可能存在內存泄漏,這時需要開啟該視圖的Memory Views視圖的Recorded Objects子視圖,開啟前的視圖請見:圖3,開啟后視圖如下:



 圖:5



 圖:6

如圖6,在該視圖里打開右鍵菜單,不斷切換GC、Live和GC Live這三種模式,並結合項目的Java類,找出本該被回收但卻沒有得到回收的對象的對應Java類,從而找出問題根源。

分析CPU

通常一個方法的執行時間越長則占用CPU的資源則越多,在JProfiler里就是通過方法的執行時間來描述對CPU的使用情況。如圖:

 

 在圖中,可以發現JProfiler以很清楚的層級結構描述出在一段時間里涉及類方法的執行時間,這些時間是從開始記錄到查看該視圖這段時間所發生的執行時間的合計,如此可以准確反映出真實場景下的方法執行情況。

   一般是用LoadRunner壓一段時間后再查看該視圖,通過占用時間的不同,找出系統里最耗時的類方法進行調優解決問題。

   發現執行一次請求,響應時間不能滿足需求時,通過這種CPU時間占有的方式分析可優化點是一種簡單而有效的方式。

分析線程

 

線程的運行情況可以直接反應出系統的瓶頸所在,對線程一般有以下三個關注點:

  1. Web容器的線程最大數管理,Web容器允許開啟的線程數與系統要求的最大並發數有一定的對應關系,通常是Web容器運行的線程數略大於最大並發數,以Tomcat為例,在{$tomcat}/conf/server.xml文件的Connector選項里配置maxThreads,它的默認值時150;
  2. 線程阻塞;
  3. 線程死鎖。

在JProfiler里有專門的線程視圖:Thread Views,該視圖能很好的發現並解決線程相關的大多問題。線程運行歷史圖:


如圖在Thread Views的Thread History視圖里可以查看Web容器共打開的線程數以及這些線程的使用情況,在視圖里紅色表示阻塞的時間段,紅色線條越長代表阻塞的時間越長

參考:http://blog.csdn.net/adermxl/article/details/37725151


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2026 CODEPRJ.COM