定位任意時刻性能問題，持續性能分析實踐解析

作者：義泊

01 持續性能剖析簡介

更好的應用性能，可以提供更好的用戶體驗，可以降低企業IT成本，可以讓系統更穩定和可靠。在應用性能剖析技術出現以前，開發人員排查問題只能依賴各種日誌和監控，這需要提前在應用代碼中埋點，不但對應用代碼侵入性較大且可能由於埋點不全而無法提供足夠信息，診斷問題非常費時，很多時候無法找出原因。

隨着應用性能剖析技術出現，開發人員可以很方便的找出應用程序性能瓶頸（如CPU利用率高、內存佔用高等），從而進行優化。但由於早期應用性能剖析技術開銷較大，只能在開發環境而不能在生產長時間開啓，生產環境出問題時很可能沒有被記錄下來，開發人員在開發環境模擬和復現問題很困難，導致解決問題的效率很低，也很有可能無法解決。

近些年來，性能剖析技術持續發展，功能越來越豐富，開銷也顯著改善，達到生產環境持續開啓水準，不過離廣泛普及還存在諸多障礙。性能剖析一般過程有三步：生產環境抓取、保存性能剖析文件、性能剖析文件可視化。當應用體量較大時，這3個步驟每步都存在着難度，需要解決大量計算、存儲、產品設計等多方面問題。

**ARMS Continuous Profiler [ 1] 應運而生，由阿里雲ARMS（應用實時監控服務 [ 2] ）團隊和Dragonwell [ 3] **團隊聯合研發。它基於當前最成熟的性能剖析技術，將整個性能剖析過程產品化，適合在生成環境持續開啓。與常規性能剖析相比，ARMS Continuous Profiler增加時間維度，核心功能如下：

定位任意時刻的性能問題（比如CPU佔用高、內存佔用高）
支持兩個時段的性能對比，找出應用演進過程中的性能差異
觀測應用的調用棧，以便更好的審視和理解代碼設計

02 ARMS 持續性能分析功能演示

我們舉例來說明如何用ARMS持續性能分析來解決問題。

常見場景一：CPU 熱點解析

問題現象

以某圖書館的服務應用舉例，其Java進程佔用大量CPU，接口響應時間達到了十多秒，應用性能很差。

找出熱點方法

因爲當前應用CPU佔用很高，因此我們直接在性能分析類型中選擇CPU Time菜單路徑：ARMS控制檯 -> 應用首頁 -> 應用診斷 -> CPU&內存診斷

從火焰圖我們可以看到，java.util.LinedList.node(int)方法佔用了85%的CPU，對應的業務代碼方法是DemoController.countAllBookPages(List)，結合代碼，可以發現，這個方法對於對象很多的集合性能很差，因爲要從頭或者從尾部逐個遍歷。

修復問題

定位到原因後，我們可以通過兩個解決方案進行修復。第一個方法是將LinkedList修改爲下標訪問方式更高效的ArrayList

第二個方法是將LinkedList的遍歷算法從普通for循環修改爲增強的for循環

性能驗證

將修復後的代碼重新部署，以相同壓力分別壓測兩種方案，可以看到接口響應時間顯著下降，Java進程CPU利用率顯著下降。

常見場景二：內存申請熱點

問題現象

以某圖書館的服務應用舉例，其Java進程佔用大量CPU，接口響應時間達到十多秒，應用性能很差。

找出熱點方法

因爲當前應用CPU佔用很高，我們直接在性能分析類型中選擇：CPU Time菜單路徑：ARMS控制檯 -> 應用首頁 -> 應用診斷 -> CPU&內存診斷

從CPU熱點方法，我們發現Java進程89%的時間都在做GC，說明應用存在很大的內存壓力。我們下一步選擇內存熱點剖析。

從上圖的內存申請熱點火焰圖，我們可以找到過去一段時間所有內存申請中，DemoController.queryAllBooks方法佔了99%，進一步檢查，可以發現業務代碼創建了2萬個大對象並保存到了List。

注：這個方法本來應該從數據庫中讀取2萬本書，這裏進行了簡化，但效果相同，都是在堆中創建了一個佔用大量內存的List

修復問題

這個接口本來想實現的是按分頁查詢書籍列表，但由於實現錯誤，誤將所有書籍都查出來了然後最終只返回了指定分頁的部分，所以可以直接從數據庫中用分頁的方式查詢，這樣就可以避免大量的Java內存佔用。

性能驗證

將修復後的代碼重新部署，以前相同壓力進行壓測，可以看到接口響應時間顯著下降，Java進程CPU利用率顯著下降。

03 ARMS 持續性能分析的設計和實現

1、產品設計

產品整體分爲3個部分，第一個部分負責在應用端收集性能剖析數據，第二個部分用於傳輸和存儲剖析結果文件，第三部分用於查詢和展示。

第一個部分主要使用**Java Flight Recorder [ 4] 、async-profiler [ 5] **，我們會根據Java版本情況自動選擇其一，其核心功能是週期性對應用程序進行採樣，並且不會因爲安全點問題導致結果不準確。下圖是對一個線程採樣6次的例子，可以看到每次採樣瞬間的調用棧。最終保存爲JFR格式的文件。