概要
Java性能分析是一門藝術和科學。科學指的是性能分析通常都包括大量的數字、測量和分析；藝術指的是知識、經驗和直覺的使用。性能分析的工具或者手段各有千秋，但性能的分析的過程卻都截然不同。本文就已知適用的Java性能分析竅門進行一些分享，幫助用戶更好的理解和運用。算法
竅門一：線程棧剖析
線程棧分析是對正在運行的Java線程的快照分析，是一種輕量級的分析手段，用戶在不清楚應用存在什麼性能問題的時候可優先嚐試。雖然斷定Java線程是否異常並無統一的標準，但用戶能夠經過一些指標進行定量的評估。如下分享4個檢測指標：後端
1)線程死鎖檢查 線程死鎖檢查是一個很是有價值的檢測指標。若是線程死鎖，則通常存在系統資源的浪費或服務能力降低等問題，一旦發現就須要及時處理。線程死鎖檢測會展現線程死鎖關係以及對應的棧信息，經過分析便可定位到觸發死鎖的代碼。如圖-1所示死鎖模型展現了一個複雜的4線程死鎖場景。緩存
2)線程統計檢查 狀態統計是對運行的線程按照運行狀態進行的統計和彙總。用戶在不徹底瞭解本身業務壓力的狀況下，對於可用線程數通常會配置一個很是充裕的範圍，這樣反而會由於過多的線程致使性能降低或者系統資源耗盡。如圖-2所示，能夠發現超過90%的線程處於阻塞和等待狀態，那麼適當優化線程數量是能夠減小線程調度帶來的開銷以及沒必要要的資源浪費。性能優化
如圖-3所示，處於運行階段的線程數已經超過90%，進一步分析可能存在線程泄露的問題。同時，運行的線程太多，線程切換的開銷也是很是大的。併發
3)線程CPU使用率檢查 對各Java線程CPU使用狀況進行統計和排序，針對CPU使用率極高的線程線程棧進行分析，能夠快速定位到程序熱點。如圖-4所示，首個任務線程的CPU使用率達已經到100%，則開發人員可根據業務邏輯肯定是否進行代碼優化。框架
4)GC線程數檢查 GC線程數每每是容易被用戶忽視的指標。用戶在設置並行GC線程數的時候容易忽視系統的資源狀況，或者隨意將應用部署在CPU核數較多的物理機。如圖-5所示，咱們發如今一個4核8GB的容器中G1的併發收集線程數爲9（通常狀況下並行GC的線程數是GC任務線程數的1/4），也就是在GC發生的時候可能會出現9個並行的GC線程，這種狀況下CPU資源會被短期直接耗盡而系統和業務阻塞。因此在使用GC收集器（如CMS、 G1）的時候儘量設置或者關注GC的線程數。socket
竅門二：GC日誌剖析
日誌分析是對Java程序GC收集記錄數據的分析，而這部分數據的收集是須要開啓特定選項的。因此，在啓動Java程序前必定要增長日誌參數（如JDK8：-Xloggc:logs/gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps；JDK11：-Xlog:gc*:logs/gc-%t.log:time,uptime）。GC日誌分析的結果描述的是在過去一段時間內Java程序就內存回收的狀態。經過分析這些狀態信息，用戶能夠很是方便的得到到GC參數甚至Java代碼優化的指標數據。如下就3個分析指標進行展開：工具
1)GC的吞吐率 吞吐率描述的是在JVM運行時間段可用於業務處理的時間佔比，即非GC佔用時間。該值越大表示用戶GC佔用的時間越少，JVM性能越好。JVM內部指定該值不能低於90%，不然JVM自己所帶來的性能損耗就會嚴重影響業務性能。如圖-6所示是JDK8的CMS運行3小時左右的日誌分析結果，分析結果顯示其吞吐率超過99.2%，JVM（GC）致使的性能損耗是比較低的。性能
2)暫停時間統計 GC暫停時間指的是在GC過程當中須要中止業務線程運行的時間，該時間須要在在一個合理的範圍內。若是絕大部分的暫停時間超過預期（用戶能夠接受的範圍），則頗有須要去調整GC參數以及堆大小，甚至設置並行GC線程數。如圖-7所示，95%以上的GC暫停時間是在40ms之內；而超過100ms的暫停多是致使業務請求時間毛刺的主要因素。爲了消除暫停時間波動問題，能夠選擇如G1 GC或ZGC，或者調整並行線程數或者GC參數等。測試
3)GC階段散點圖 散點圖反映的是每一次GC操做釋放的內存大小的分佈狀況。如圖-8所示，每次GC釋放的內存大小基本一致，說明內存釋放過程比較穩定。但若是出現比較大的波動或者出現比較多的Full GC則有多是新生代區堆空間不足致使晉升量較大；若是每次GC的釋放量比較少有多是G1 GC自適應算法致使的新生代空間較小等等。由於散點圖展現的數據有限，因此通常須要結合其它指標以及用戶的JVM參數進行聯合分析。
竅門三：JFR事件剖析
JFR是Java Flight Record的縮寫，是JVM內置的基於事件的JDK監控記錄框架。社區中，JFR優先於OpenJDK11上發佈，後移植到OpenJDK8的較高版本260上，且沿用了統一的使用接口與操做命令jcmd。同時，因爲JFR錄製通常對應用影響很小（默認開啓的性能影響在1%之內），適合長時間開啓；且JFR能收集到如Runtime、GC、線程棧、堆、IO等在內的豐富信息，很是方便用戶瞭解Java程序的運行情況。 JFR錄製的事件有100多種，若是程序複雜每每不到10分鐘錄製的JFR文件大小就會超過500MB，因此用戶在分析時每每並非全部的信息都會關注。如下就業務性能中常見幾個作一下分享：
1)進程CPU佔用率 CPU採樣默認間隔是1s，基本能及時反映當前進程的CPU平均使用狀況。在出現CPU持續偏高，或者CPU出現相似圖-9所示的CPU偶發飆高的狀況時，均可以進行必定的檢測和分析。經過進一步定位，此處CPU飆高與GC觸發時間一致，初步確認是GC致使的CPU變化。
2)GC配置及暫停分佈 GC配置能夠幫助咱們瞭解到當前進程的GC收集器及其主要的配置參數，由於不用的收集器特性會不一樣，分析堆空間、觸發控制等參數也是很是重要的。控制參數能夠幫助咱們理解GC收集過程，好比圖-10所示的G1收集器，設置的最大堆爲8GB，GC暫停時間在40ms左右（默認預期200ms），是遠低於預期值的。進一步分析參數發現設置了NewRatio值爲2（對G1 GC不太熟悉的狀況下，用戶很容易設置該參數），致使新生代區的GC觸發頻繁，並且從數據看未觸發混合GC。爲了增長對堆空間的利用，能夠移除NewRatio參數，增長新生代區的最大值比例（由於未觸發混合GC，說明堆回收時晉升量很是低），下降回收塊的回收門檻等，進而增長對整堆的使用。經過優化，堆空間的使用從原來的4GB提升到7GB，YGC頻率從20s/次提升到平均40s/次，GC暫停時間沒有明顯變化。
3)方法採樣火焰圖 方法火焰圖是對調用方法採樣次數的統計，比例越大表示調用次數越多。由於採樣過程當中有棧的完整信息，對於用戶來講是很是比較直觀的，性能優化的幫助性大增。如圖-11所示，能夠很清楚的看到GroupHeap.match執行次數比例接近30%，能夠做爲性能優化點。
4)IO讀寫性能 檢查IO性能多半是對程序處理性能出現突變的場景，好比降低或飆升。如從socket讀入的數據量飆升，致使處理業務的CPU飆高；或者由於須要寫出的數據變多，致使業務線程阻塞，處理能力降低等。如圖-11所示，能夠經過讀取/寫入趨勢圖判斷在監控時間段的IO能力。
竅門四：堆內容剖析
堆內容分析是分析Java堆OOM（OutOfMemoryError）緣由的經常使用手段。OOM主要有堆空間溢出、元空間溢出、棧空間溢出和直接內存溢出等，但並非全部溢出狀況均可以經過堆內容分析得到。對於堆轉儲的文件而言，內存溢出的可能性是不肯定的，但能夠經過一些定量的指標或者約定的條件做出判斷，再經過開發或者測試人員進行最後的確認。如下分享三個有價值的衡量指標：
1)大對象檢查 統計大對象分佈信息能夠幫助咱們瞭解內存消耗在這部分對象上的比重，以及存在的大對象是否合理。過多的大對象沒法釋放會更快的耗盡內存而出現OOM，相比全量的分析全部對象而言，大對象的檢查是具備表明性的，如圖-13所示。
2)類加載檢查 類加載統計主要統計的是程序當前加載的所有類信息，是計算元空間佔用的重要數據。過多的加載類信息也會致使元空間被大量佔用，在相似RPC場景下，緩存加載類信息是容易觸發OOM的。
3)對象泄露檢查 首先引入三個概念； 淺堆：一個對象所佔用的內存大小，和對象的內容無關，只和對象的結構有關。 深堆：一個對象被GC回收後，能夠真實釋放的內存大小，即經過該對象訪問到的全部對象的淺堆之和（支配樹）。 支配樹：在對象的引用圖中，全部指向對象B的路徑都通過對象A，則認爲對象A支配對象B；若是對象A是離對象B最近的一個支配對象，則認爲對象A爲對象B的直接支配者。 按照GC策略，堆中的對象只可能有兩種狀態，一種是經過GC的根可達的對象；另外一種是經過GC根不可達的對象。不可達的對象會被GC收集器回收，對應的內存就會返回到系統中去。而可達對象都是被用戶直接或者間接引用的對象，因此對象泄露針對的就是被用戶間接引用但永遠不會被使用的對象，這些對象由於被引用而沒法釋放。對象泄露不是絕對的，而是相對的，通常沒有確切的標準，但能夠經過對對象的深堆大小進行評估。好比檢測到HashMap存放了4844個對象（如圖-14所示），計算HashMap淺堆約115KB，看到這裏可能以爲沒有什麼問題；但經過計算對象的深堆發現其超過500MB。這種狀況下，若是沒法釋放HashMap而持續增長新的鍵值就有可能致使堆內存耗盡而出現OOM。
做者簡介：
Nianwu，高級後端工程師
主要負責Java性能平臺和JDK支持，對缺陷檢查和編譯器也有深刻研究。
獲取更多精彩內容，請關注[OPPO互聯網技術]公衆號