hprof怎么用

這篇文章主要為大家展示了“hprof怎么用”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“hprof怎么用”這篇文章吧。

1、示例演示

例子程序：

注：這是一段測試代碼通過sleep方法進行延時，在程序運行過程中很慢，我想知道到底是哪段程序影響的整體性能呢？

我在這個Java程序中，加了如下運行參數：

-agentlib:hprof=cpu=times,interval=10

/*     times：java函數的執行時間    hprof=cpu是針對cpu統計時間    interval=10 采樣10次 */

再次運行這段程序顯示如下圖：

 
這時候還發現在工程目錄里面，多了一個文本文件java.hprof.txt

內容如下：

注：通過上面內容可以看到，哪個類的方法執行時間長，耗費了cpu時間，一目了然，方便我們快速定位問題。

2、命令的具體講解 
hprof不是獨立的監控工具，它只是一個Java agent工具，它可以用在監控Java應用程序在運行時的CPU信息和堆內容，使用java -agentlib:hprof=help命令可以查看hprof的使用文檔。

通過上圖可以看到這個工具非常強大，可以統計的東西很多，上面的例子統計的是cpu時間，同樣我們還可以統計內存占用的dump信息。 
如：-agentlib:hprof=heap,format=b,file=/test.hprof

這個hprof小工具，非常方便我們在用JUnit自測代碼的時候結合使用，既可以解決業務上的BUG，又能夠在一定程序上解決可發現的性能問題，非常實用。

二、性能排查工具-pidstat

1、示例演示 
例子程序：

注：這是一段測試用的java程序，將其運行起來。

在命令行輸入：

pidstat -p 843 1 3 -u -t

/* -u：代表對cpu使用率的監控參數1 3：表示每秒采樣一次，一共三次   -t：將監控級別細化到線程 */

運行命令顯示如下圖所示： 

 
注：其實中TID就是線程ID，%usr表示用戶線程使用率，從圖中可以看到855這個線程占用cpu非常的高。

再輸入如下命令：

jstack -l 843 > /tmp/testlog.txt

查看testlog.txt顯示如下部分內容：

 
注：我們關注的是日志文件的NID這個字段，它對應的就是我們上面說的TID，NID是TID的16進制表示，將上面的十進制855轉換成十六進制為357，在日志中進行搜索看到如下內容：

以此可以推斷出有性能瓶頸的程序點。

2、pidstat具體命令詳解 
pidstat是一個功能非常強大的性能監測工具，他是Sysstat的組件之一，可以從http://sebastien.godard.pagesperso-orange.fr/download.html 進行下載，下載后可以通過./configure等命令進行安裝，這個命令的強大之處在于不僅可以監控進程的性能情況，也可以監控線程的性能情況。

pidstat監控cpu常用顯示字段內容如下：

pidstat監控io常用的字段顯示內容如下：

三、一個內存溢出案例分析

1、內存溢出現象 
系統共有8臺服務器，每次隨機只有一臺服務器報java.lang.OutOfMemoryError: GC overhead limit exceeded錯誤，然后接著就報內存溢出錯誤java.lang.OutOfMemoryError: Java heap space。

2、理論支撐 
我們先解釋一下什么是GC overhead limit exceeded錯誤。

GC overhead limt exceed檢查是Hotspot VM 1.6定義的一個策略，通過統計GC時間來預測是否要OOM了，提前拋出異常，防止OOM發生。Sun 官方對此的定義是：“并行/并發回收器在GC回收時間過長時會拋出OutOfMemroyError。過長的定義是，超過98%的時間用來做GC并且回收了不到2%的堆內存。用來避免內存過小造成應用不能正常工作。

可以看到當堆中的對象無法被收回的時候，就提前遇警報出這樣的錯誤，此時內存并沒有溢出，這個特性在JDK中是默認添加的。

3、DUMP文件分析 
將dump文件導入VisualVM工具中，如下圖所示：

通過上圖可以看出類結構圖中，最占用內存的是char[]，LinkedHashMap和String三項。但是這三項的實例數并沒有占滿，看樣子不會內存溢出，怎么才能具體分析呢？原因就在于GC overhead limt exceed，這個錯并不會在內存真正溢出才會報，所以通過dump文件，我們只能自己去判斷分析，哪些項有可能會造成溢出，我們進入char[]項具體來看，會發現里面有很多hessian的url字符被緩存，通過排除程序可以看到由于底層中間件程序為了提高“性能”，將每次調用的url都緩存起來，不用每次都生成，但沒有相應緩存釋放操作，于是造成了大量字符對象長期持有從而報錯，在此就不截圖來具體看代碼，涉及一些公司信息。

4、問題解決方案 
* 可以添加JVM的啟動參數來去掉提前報警限制：-XX:-UseGCOverheadLimit，于其讓應用每次都提前報警，還不如讓暴風雨來的更猛些，直接內存溢出，因為服務器是集群，其中一臺掛掉不會影響線上正常交易，同時也方便我們通過日志來排錯。

• 通過排查程序，檢查系統是否有使用大內存的代碼不釋放或死循環。

以上是“hprof怎么用”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！