JProfiler是一款專門為Java推出的性能分析軟件,它的主要功能是幫助用戶監視JVM的運行情況和性能,通過對系統內存使用情況的監控,幫助用戶分析程序中存在的各種問題。JProfiler使用起來很簡單,是大家剖析Java必備的工具,有需要的用戶敬請下載。
使用方便
界面操作友好
對被分析的應用影響小
CPU、Thread、Memory分析功能尤其強大
支持對jdbc、noSql、jsp、servlet、socket等進行分析
支持多種模式(離線,在線)的分析
JProfiler是一個全功能的Java剖析工具(profiler),專用于分析J2SE和J2EE應用程序。它把CPU、執行緒和內存的剖析組合在一個強大的應用中。JProfiler可提供許多IDE整合和應用服務器整合用途。JProfiler直覺式的GUI讓你可以找到效能瓶頸、抓出內存漏失(memoryleaks)、并解決執行緒的問題。它讓你得以對heapwalker作資源回收器的Rootanalysis,可以輕易找出內存漏失;heap快照(snapshot)模式讓未被參照(reference)的對象、稍微被參照的對象、或在終結(finalization)隊列的對象都會被移除;整合精靈以便剖析瀏覽器的Java外掛功能。
1、雙擊“jprofiler_windows-x64_11_0.exe”開始加載安裝包
2、進入到安裝界面,默認安裝到C盤,選擇第二項可以自定義
3、點擊next出現許可協議,選擇第一項也就是我同意
4、選擇軟件安裝目錄,默認為“C:\Program Files\jprofiler11”
5、繼續next就會開始jprofiler 11的安裝了
6、稍等一會兒完成jprofiler 11的安裝
JProfiler 設置
數據采集模式
JProfier 提供兩種數據采集模式 Sampling 和 Instrumentation。
Sampling - 適合于不要求數據完全精確的場景。優點是對系統性能的影響較小,缺點是某些特性不支持(如方法級別的統計信息)。
Instrumentation - 完整功能模式,統計信息也是精確的。缺點是如果需要分析的類比較多,對應用性能影響較大。為了降低影響,往往需要和 Filter 一起使用。
由于我們需要獲取方法級別的統計信息,這里選擇了 Instrumentation 模式。同時配置了 Filter,讓 agent 只記錄位于 Java 包com.aliyun.openservices.aliyun.log.producer下的類和類com.aliyun.openservices.log.Client的 CPU 分析數據。
應用啟動模式
通過為 JProfiler agent 指定不同的參數可以控制應用的啟動模式。
等待模式 - 只有在 Jprofiler GUI 和 agent 建立連接并完成分析配置設置后,應用才會真正啟動。在這種模式下,您能夠獲取應用啟動時期的分析數據。對應的命令為-agentpath:=port=8849。
立即啟動模式 - 應用會立即啟動,Jprofiler GUI 會在需要時和 agent 建立連接并設置分析配置。這種模式相對靈活,但會丟失應用啟動初期的分析數據。對應的命令為-agentpath:=port=8849,nowait。
離線模式 - 通過觸發器記錄數據、保存快照供事后分析。對應的命令為-agentpath:=offline,id=xxx,config=/config.xml。
因為是在測試環境,同時對應用啟動初期的性能也比較關注,這里選擇了默認的等待模式。
使用 JProfiler 診斷性能
在完成 JProfiler 的設置后,便可以對 Producer 的性能進行診斷。
Overview
在概覽頁我們可以清晰的看到內存使用量、垃圾收集活動、類加載數量、線程個數和狀態、CPU 使用率等指標隨時間變化的趨勢。
通過此圖,我們可以作出如下基本判斷:
程序在運行過程中會產生大量對象,但這些對象生命周期極短,大部分都能被垃圾收集器及時回收,不會造成內存無限增長。
加載類的數量在程序初始時增長較快,隨后保持平穩,符合預期。
在程序運行過程中,有大量線程處于阻塞狀態,需要重點關注。
在程序剛啟動時,CPU 使用率較高,需要進一步探究其原因。
CPU views
CPU views 下的各個子視圖展示了應用中各方法的執行次數、執行時間、調用關系等信息,能幫我們定位對應用性能影響最大的方法。
Call Tree
Call tree 通過樹形圖清晰地展現了方法間的層次調用關系。同時,JProfiler 將子方法按照它們的執行總時間由大到小排序,這能讓您快速定位關鍵方法。
對于 Producer 而言,方法SendProducerBatchTask.run()耗時最多,繼續向下查看會發現該方法的主要時間消耗在了執行方法Client.PutLogs()上。
Hot Spots
如果您的應用方法很多,且很多子方法的執行時間比較接近,使用 hot spots 視圖往往能助您更快地定位問題。該視圖能根據方法的單獨執行時間、總執行時間、平均執行時間、調用次數等屬性對它們排序。其中,單獨執行時間等于該方法的總執行時間減去所有子方法的總執行時間。
在該視圖下,可以看到Client.PutLogs(),LogGroup.toByteArray(),SamplePerformance$1.run()是單獨執行時間耗時最多的三個方法。
Call Graph
找到了關鍵方法后,call graph 視圖能為您呈現與該方法直接關聯的所有方法。這有助于我們對癥下藥,制定合適的性能優化策略。
這里,我們觀察到方法Client.PutLogs()執行的主要時間花費在了對象序列化上,因此性能優化的關鍵是提供執行效率更高的序列化方法。
Live memory
Live memory 下的各個子視圖能讓您掌握內存的具體分配和使用情況,助您判斷是否存在內存泄漏問題。
All Objects
All Objects 視圖展示了當前堆中各種對象的數量和總大小。由圖可知,程序在運行過程中構造出了大量 LogContent 對象。
Allocation Call Tree
Allocation Call Tree 以樹形圖的形式展示了各方法分配的內存大小。可以看到,SamplePerformance$1.run()和SendProducerBatchTask.run()是內存分配大戶。
Allocation Hot Spots
如果方法比較多,您還可以通過 Allocation Hot Spots 視圖快速找出分配對象最多的方法。
Thread History
線程歷史記錄視圖直觀地展示了各線程在不同時間點的狀態。
不同線程執行的任務不同,所展現的狀態特征也不同。
線程pool-1-thread-會循環調用producer.send()方法異步發送數據,它們在程序剛啟動時一直處于運行狀態,但隨后在大部分時間里處于阻塞狀態。這是因為 producer 發送數據的速率低于數據的產生速率,且單個 producer 實例能緩存的數據大小有限。在程序運行初始,producer 有足夠空間緩存待發送數據,所以pool-1-thread-一直處于運行狀態,這也就解釋了為何程序在剛啟動時 CPU 使用率較高。隨著時間的推移,producer 的緩存被逐漸耗盡,pool-1-thread-必須等到 producer “釋放”出足夠的空間才有機會繼續運行,這也是為什么我們會觀察到大量線程處于阻塞狀態。
aliyun-log-producer-0-mover負責將超時 batch 投遞到發送線程池中。由于發送速率較快,batch 會因緩存的數據達到了上限被pool-1-thread-直接投遞到發送線程池中,因此 mover 線程在大部分時間里都處于等待狀態。
aliyun-log-producer-0-io-thread-作為真正執行數據發送任務的線程有一部分時間花在了網絡 I/O 狀態。
aliyun-log-producer-0-success-batch-handler用于處理發送成功的 batch。由于回調函數比較簡單,執行時間短,它在大部分時間里都處于等待狀態。
aliyun-log-producer-0-failure-batch-handler用于處理發送失敗的 batch。由于沒有數據發送失敗,它一直處于等待狀態。
通過上述分析可知,這些線程的狀態特征都是符合預期的。
Overhead Hot Spots Detected
當程序運行結束后,JProfiler 會彈出一個對話框展示那些頻繁被調用,但執行時間又很短的方法。在下次診斷時,您可以讓 JProfiler agent 在分析過程中忽略掉這些方法以減輕對應用性能的影響。