編者按：程超在圈裡有讀三遍經典文章的習慣，江湖人稱三遍哥，程超作為易寶支付的架構師，有10多年的java開發經曆，專注于金融支付與大資料領域，他将工作之中遇到的問題和經驗都分享在簡書（<b>小程故事多</b>）裡面，小編略微采集小部分放到中生代公衆号裡，以飨讀者！
最近在工作中經常和性能壓測工作打交道，積累了一些性能分析經驗，我覺得這些經驗對每一個開發者都有幫助的，能開發出性能高的代碼也是我們的最終目标。
由易到難，我們逐漸介紹不同指令的用法和好處，這些指令是如何幫助我們開發人員進行性能分析的。
一、開發者的自測利器-hprof指令
1、示例示範
例子程式：
注：這是一段測試代碼通過sleep方法進行延時，在程式運作過程中很慢，我想知道到底是哪段程式影響的整體性能呢？
我在這個java程式中，加了如下運作參數：
再次運作這段程式顯示如下圖：
這時候還發現在工程目錄裡面，多了一個文本檔案java.hprof.txt，如下圖所示：
内容如下：
cpu time (ms) begin (total = 11542) fri jul 22 11:00:34 2016
rank self accum count trace method
1 86.65% 86.65% 1 303422 com.test.hproftest.slowermethod
2 8.66% 95.31% 1 303423 com.test.hproftest.slowmethod
3 0.25% 95.56% 36 300745 java.util.zip.zipfile.<init>
4 0.20% 95.76% 36 300434 java.lang.string.equals
5 0.13% 95.89% 14 301138 java.net.urlstreamhandler.parseurl
6 0.11% 96.01% 6 301339 java.net.urlclassloader$1.run
7 0.10% 96.10% 14 301124 java.lang.string.<init>
8 0.09% 96.19% 3407 300355 java.lang.string.charat
9 0.08% 96.27% 36 300443 java.io.unixfilesystem.normalize
注：通過上面内容可以看到，哪個類的方法執行時間長，耗費了cpu時間，一目了然，友善我們快速定位問題。
2、指令的具體講解
hprof不是獨立的監控工具，它隻是一個java agent工具，它可以用在監控java應用程式在運作時的cpu資訊和堆内容，使用<code>java -agentlib:hprof=help</code>指令可以檢視hprof的使用文檔。
通過上圖可以看到這個工具非常強大，可以統計的東西很多，上面的例子統計的是cpu時間，同樣我們還可以統計記憶體占用的dump資訊。
如：<code>-agentlib:hprof=heap,format=b,file=/test.hprof</code>
這個hprof小工具，非常友善我們在用junit自測代碼的時候結合使用，既可以解決業務上的bug，又能夠在一定程式上解決可發現的性能問題，非常實用。
二、性能排查工具-pidstat
注：這是一段測試用的java程式，将其運作起來。
在指令行輸入：
運作指令顯示如下圖所示：
注：其實中tid就是線程id，%usr表示使用者線程使用率，從圖中可以看到855這個線程占用cpu非常的高。
再輸入如下指令：
檢視testlog.txt顯示如下部分内容：
注：我們關注的是日志檔案的nid這個字段，它對應的就是我們上面說的tid，nid是tid的16進制表示，将上面的十進制855轉換成十六進制為357，在日志中進行搜尋看到如下内容：
以此可以推斷出有性能瓶頸的程式點。
2、pidstat具體指令詳解
pidstat是一個功能非常強大的性能監測工具，他是sysstat的元件之一，可以從http://sebastien.godard.pagesperso-orange.fr/download.html 進行下載下傳，下載下傳後可以通過<code>./configure</code>等指令進行安裝，這個指令的強大之處在于不僅可以監控程序的性能情況，也可以監控線程的性能情況。
pidstat監控cpu常用顯示字段内容如下：
pidstat監控io常用的字段顯示内容如下：
三、一個記憶體溢出案例分析
1、記憶體溢出現象
系統共有8台伺服器，每次随機隻有一台伺服器報<code>java.lang.outofmemoryerror: gc overhead limit exceeded</code>錯誤，然後接着就報記憶體溢出錯誤<code>java.lang.outofmemoryerror: java heap space</code>。
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，于其讓應用每次都提前報警，還不如讓暴風雨來的更猛些，直接記憶體溢出，因為伺服器是叢集，其中一台挂掉不會影響線上正常交易，同時也友善我們通過日志來排錯。
通過排查程式，檢查系統是否有使用大記憶體的代碼不釋放或死循環。
文／小程故事多（簡書作者）
程超，易寶支付架構師，有10多年的java開發經曆，專注于金融支付與大資料領域，他将工作之中遇到的問題和經驗都分享在簡書和csdn部落格。