作者介紹
程超，易寶支付架構師，10年java工作經驗，擅長分布式和大資料技術領域，目前主要從事金融支付類方性能分析向。
最近在工作中經常和性能壓測工作打交道，積累了一些性能分析經驗，我覺得這些經驗對每一個開發者都有幫助的，能開發出性能高的代碼也是我們的最終目标。
由易到難，我們逐漸介紹不同指令的用法和好處，這些指令是如何幫助我們開發人員進行性能分析的。
一開發者的自測利器-hprof指令
1、示例示範
例子程式：
注：這是一段測試代碼通過sleep方法進行延時，在程式運作過程中很慢，我想知道到底是哪段程式影響的整體性能呢？
我在這個java程式中，加了如下運作參數：
再次運作這段程式顯示如下圖：
這時候還發現在工程目錄裡面，多了一個文本檔案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
注：這是一段測試用的java程式，将其運作起來。
在指令行輸入：
運作指令顯示如下圖所示：
注：其實中tid就是線程id，%usr表示使用者線程使用率，從圖中可以看到855這個線程占用cpu非常的高。
再輸入如下指令：
檢視testlog.txt顯示如下部分内容：
注：我們關注的是日志檔案的nid這個字段，它對應的就是我們上面說的tid，nid是tid的16進制表示，将上面的十進制855轉換成十六進制為357，在日志中進行搜尋看到如下内容：
以此可以推斷出有性能瓶頸的程式點。
2、pidstat具體指令詳解
pidstat監控cpu常用顯示字段内容如下：
1、pid - 被監控的任務的程序号
2、%usr - 當在使用者層執行（應用程式）時這個任務的cpu使用率，和 nice 優先級無關。注意這個字段計算的cpu時間不包括在虛拟處理器中花去的時間。
3、%system - 這個任務在系統層使用時的cpu使用率。
4、%guest - 任務花費在虛拟機上的cpu使用率（運作在虛拟處理器）。
5、%cpu - 任務總的cpu使用率。在smp環境（多處理器）中，如果在指令行中輸入-i參數的話，cpu使用率會除以你的cpu數量。
6、cpu - 正在運作這個任務的處理器編号。
7、command - 這個任務的指令名稱。
pidstat監控io常用的字段顯示内容如下：
1、kb_rd/s - 任務從硬碟上的讀取速度（kb）
2、kb_wr/s - 任務向硬碟中的寫入速度（kb）
3、kb_ccwr/s - 任務寫入磁盤被取消的速率（kb）
三一個記憶體溢出案例分析
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，于其讓應用每次都提前報警，還不如讓暴風雨來的更猛些，直接記憶體溢出，因為伺服器是叢集，其中一台挂掉不會影響線上正常交易，同時也友善我們通過日志來排錯。
通過排查程式，檢查系統是否有使用大記憶體的代碼不釋放或死循環。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-07-27</b>