Java性能分析工具之Jprofiler初體驗

近日，老大跟我頻繁抱怨java項目耗了他家服務器太多cpu資源、占了太多數據庫連接、項目進度太慢貽誤戰機等等——不免感嘆java程序員的艱辛，像我一初出茅廬山野村夫，真不懂這些；心生歉疚，茶飯不思，夜不能寐，眼看郁結成疾，虧得邂逅Jprofiler，才給了我生的希望——

【JProfiler】是一個全功能的 Java 剖析工具，專用於分析 J2SE 和 J2EE 應用程序。它把 CPU 、執行緒和內存的剖析組合在一個強大的 應用中。 JProfiler 可提供許多 IDE 整合和應用服務器整合用途。 JProfiler 可以查看當前應用的對象、對象引用、內存、CPU使用情況、線程、線程運行情況（阻塞、等待、效能瓶頸、內存泄露 memory leaks等），同時可以查找應用內存使用得熱點，即：哪個對象占用的內存比較多；或者CPU熱點，即：哪兒方法占用的較大得CPU資源。它讓你得以對heap walker 作資源回收器的 root analysis ，可以輕易找出內存溢出； heap 快照（ snapshot ）模式讓未被參照（ reference ）的對象、稍微被參照的對象、或在終結（ finalization）隊列的對象 都會被移除；整合精靈以便剖析瀏覽器的 Java 外掛功能。

對該工具的使用總結如下：

1. JProfiler監控是要消耗系統資源的，所以一般情況下不要用於性能測試時候的監控。
2. 如果要用於相對大壓力情況下，可以有選擇的打開監控項，不用所有都打開。主要有兩個，一個是內存監控，打開的情況下可以查找內存分配熱點。一個是CPU監控，打開的情況下可以查看CPU使用熱點。 
   如圖所示，紅筆標注部分。如果兩個都關閉的話，還是可以跑一定壓力的，同時還可以監控對象數量。
3. 個人認為最好用的（也是用的最多的）是查詢當前的對象的數量。數量監控很重要，如果你使用了單例，那么你只會看到有一個對象存在，如果多了就說明程序有問題了。同樣，如果應用進行一系列操作，檢查一下該銷毀的對象是否還繼續存在，如果沒有釋放，就得考慮是否存在內存溢出了。
4. JProfiler還提供了一個比較好的檢查內存溢出得工具。他可以查找某個對象的引用情況，即：當你發現某個該釋放掉的對象沒有釋放，就可以看一下哪個實例在引用它，找到了根即找到了溢出點。
   具體操作如下：在 “Memory Views”界面中右鍵選擇你要監控的對象，選擇第一項“Take Heap Snapshot for Selection”，選擇完成后會進入“Heap Walker”界面，界面下面提供幾個功能，選擇“References”即可 。如圖：
5. JProfiler提供不同的觀察粒度，提供對類的監控、對包的監控、對J2EE組件的監控，同時過濾器也比較好用，直接定位你關注的包或類即可。
6. JProfiler的監控可能與應用之間存在一定時間差，所以有些時候需要等待刷新，才能顯示正確系統情況。

 

參考鏈接：

一、下載安裝：

1、下載地址：

http://www.ej-technologies.com/download/jprofiler/files

2、安裝圖解：

http://blog.sina.cn/dpool/blog/ArtRead.php?nid=4d5428240100svit&page=all&show=sel&vt=3

3、jprofiler注冊碼 激活：

按默認選擇“Single or evaluation license”
Name 和 Company 隨意
-----------------------憂郁的分割線---------------------------
[e-mail]#23874-hrwpdp1sh1wrn#0620
[e-mail]#36573-fdkscp15axjj6#25257
[e-mail]#5481-ucjn4a16rvd98#6038
[e-mail]#99016-hli5ay1ylizjj#27215
[e-mail]#40775-3wle0g1uin5c1#0674
--------------------------------------------------------------
[e-mail]#7009-14frku31ynzpfr#20176
[e-mail]#49604-1jfe58we9gyb6#5814
[e-mail]#25531-1qcev4yintqkj#23927
[e-mail]#96496-1qsu1lb1jz7g8w#23479
[e-mail]#20948-11amlvg181cw0p#171159

 

二、部署入門：

http://blog.csdn.net/djy1135/article/details/2304465

http://www.blogjava.net/fine/archive/2007/05/07/115671.html

詳見：

http://www.cnblogs.com/serendipity/articles/1963904.html

http://www.blogjava.net/anymobile/articles/28248.html