*作者：* *虛鏡*

## 概述

### Continuous Profiling 在軟體開發生命週期的位置

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52b7f5933b4f4f92a9699cd4a28f0f2e~tplv-k3u1fbpfcp-zoom-1.image "1.png")

CI/CD 的概念非本文重點，不解釋了。從上圖可以看出。Continuous Profiling（持續效能分析，下文簡稱為 CP）是生產向開發進行反饋的非常重要的手段。

### 發展歷史

CP 概念的起源於 Google 的論文 **[** **1]** ：

> Google Wide Profiling：A continuous Profiling infrastucture for data centers

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/afe146593bf8416fac4512fe98a61176~tplv-k3u1fbpfcp-zoom-1.image "2.png")

### 基本思路

CP 意義可以分解為兩個：

1.  效能分析(Profile)的意義：識別計算，儲存，網路上的效能瓶頸問題，建立程式碼和效能瓶頸的關聯性，從而協助開發者最佳化程式碼，解決瓶頸問題；

2.  持續(Continuous)的意義：讓效能分析貫穿應用的整個生命週期，從而解決非持續方案(如 ]on-demand)中無法抓到現場的問題。

-   **Profiling 的基本思想**

衡量程式效能最直觀的方法就是透過響應時間（Response Time，簡稱 RT）。但僅僅知道程式的執行時間很難指導我們如何把程式最佳化地更快，我們想要更進一步地瞭解這段時間之內到底發生了什麼。

讓我們先從一個例子開始，瞭解 Linux 下的時間統計告訴了使用者什麼資訊：

下面我們利用 Linux time 計算兩件事情的時間消耗：

1.  生成一個 10M 的檔案，隨機生成資料；（IO 密集）
1.  對上一步生成的檔案做個 CRC 計算；（CPU 密集）

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ef9030fbf3d453d9a5d1d78b6b07624~tplv-k3u1fbpfcp-zoom-1.image "3.png")

time 的輸出告訴使用者 3 個資訊：

-   real：總消耗時間
-   user：使用者態消耗時間
-   sys：核心態消耗時

觀察 time 的輸出，可以看出 user + sys 不等於 real，這是因為程式並不是總是 CPU 上執行的，還可能因為 IO，Lock 等等原因處於睡眠，等待的狀態，這段時間既不算在 user CPU time 也不算在 system CPU time。

-   程式在 CPU 上執行的時間（即 user CPU time  + system CPU time）稱為 CPU time（或 on-CPU time）；
-   程式處於睡眠等狀態的時間稱為 off-CPU time（or blocked time）；
-   程式實際執行的時間稱為 wall clock time（掛鐘時間）；

time 的輸出 real 對應的概念的是 wall clock time，因此可以看到：

-   對於 IO 密集型的 workload（負載），off-CPU time 是不能忽略的；
-   對於 CPU 密集型 workload（負載），on-CPU time 基本和 wall clock time 相等；

對於一個給定的執行緒（Linux 上稱為輕量級程式）：wall clock time = CPU time + off CPU time

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c8c48a7da81b40ffb046e39cdd5e7787~tplv-k3u1fbpfcp-zoom-1.image "4.png")

因此 Profile 整體分為：

-   **On-CPU**: where threads are spending time running on-CPU.
-   **Off-CPU**: where time is spent waiting while blocked on I/O, locks, timers, paging/swapping, etc.

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b8673c0b95c54fc09d9afd7fa33f6f7d~tplv-k3u1fbpfcp-zoom-1.image "5.png")

> 可以看到 Off-CPU 分析型別是一系統結果的彙總統計，因此也可以將 Off-CPU 因為引起睡眠或者等待的原因不同，可以進一步劃分為 file profiling，socket profiling，lock profiling 等等型別。

-   **Continuous 的基本思想**

持續（Continuous）相對的概念是按需（On-Demand）。

按需（或者觸發式）比較常見的問題就是無法精準的抓取現場從而導致一些偶發（難以復現）的問題無法被識別。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c5e55f55d6424cbd9a43aca161601834~tplv-k3u1fbpfcp-zoom-1.image "6.png")

比如上圖這樣一條曲線（不管它表達什麼），反正是有一段異常（或者說和大部分情況不一樣的情形），隨著自然時間的流逝；使用者發現這個異常的時候，曲線已經恢復了，因此無法在去回溯現場。這種情況下，我們發現了一段異常，但是沒有更多細節，開發者就無法知道程式碼內部發生了什麼，因此也無從談起修復和改善程式碼了。

持續則意味著貫穿整個程式的完整生命週期，不會漏掉任何一個歷史上產生過的異常。

**Continuous+Profiling 帶給開發者的意義是：在生產環節，永遠知道程式碼的所有執行細節。**

### 理解 profiling

-   **使用者互動和視覺化**

效能分析的展現形式通常以 Flame Graph 火焰圖來表達：

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/39837c315d774360a61ad5290b998a77~tplv-k3u1fbpfcp-zoom-1.image "7.png")

-   **理解火焰圖**

對火焰圖理解的本質是瞭解效能分析資料(profiling data)究竟是什麼。

效能分析資料(profiling data)就是堆疊統計資料。為了幫助讀者理解，舉個簡單的例子：

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d66b2795598442f887c9e101d49a615~tplv-k3u1fbpfcp-zoom-1.image "8.png")

橫座標表達的一個數值，在不同的場景下，可以賦予不同的含義，比如：

-   在 cpu profiling 上，表達花費時間多少；
-   在 alloc profling 上，表達成記憶體大小；
-   ......

縱座標是表達是一個 stack trace。

因此上圖表達的含義和下面一組資料是一致的。每一行以空格分割，左邊的是 stack trace，右邊是數值。

```
a();b();c() 1
a();b();d() 2
c();b() 3
```

到這裡，讀者應該對效能分析(profiling)的工作原理有個感性的認識，效能分析的整體流程如圖：

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e0de289f150e4f06b81eb19e3932b715~tplv-k3u1fbpfcp-zoom-1.image "9.png")

因此實現 profiling 的關鍵點：

1.  獲取堆疊資料（爬棧）：如何護獲取問題點（瓶頸）點的堆疊資料；
1.  生成火焰圖；

-   **常見的 Profiling Tools（生成堆疊資料）**

常見的工具如 Linux perf，eBPF profile，DTrace，SystemTap 等等，本文將這類用於獲取堆疊資料工具統稱為 Profiling Tools；Linux 這類工具的用法本文不多介紹，這類工具非常通用並且有效，但對於非C系開發者是沒那麼友好的。高階語言絕大部分應用開發者其實並不關心很低層次的內容，比如 page fault，numa banlance，context switch，L3 Cache miss 等問題，通常都不在應用開發者的知識圖譜中。這部分內容的最佳化也不再本文的目標讀者範圍，因此不多敘述。

對於 Profile Tools，我們可以將其分為兩類：

-   System Profile：which shows system code paths (eg, JVM GC, syscalls, TCP), but not Java methods.

-   language Profile：These show language methods(eg java method), but usually not system code paths.

-   -   JVM Profile
    -   golang Profile
    -   ....

不難理解，Profiling Tools 能夠爬棧就是因為在特定的程式碼裡進行的 Hook 操作，這類操作一定會產生額外的開銷。因此 Profiling Tools 會帶來額外的開銷（Overhead），不同型別的 Profiling 的 Hook 點不同，因此不同的效能分析型別會導致不同的 Overhead。**很長一段時間，無法將 Profiling 帶入生產環節最重要的阻塞點就是 Overhead 太高導致應用的業務邏輯受損嚴重。** 因此評價 Profiling Tools 是否適合上生產最重要的評估就是估算 Overhead。

### JVM Profiling

上文提到的工具基本屬於 System Profiling Tools 提供的能力，這部分工具的核心能力關注的是 system code paths；對於高階語言上一些特性，能力是不夠強的。

下面我們瞭解高階語言自身的 Profiling Tools 是如何幫助開發者來做效能最佳化的。

-   golang 內建 pprof **[** **2]**

-   java11 內建 JFR **[** **3]**
-   其他高階語言有的有自身的工具，有的沒有高階語言沒有自身工具，這類通常可以藉助 System Profiling Tools（如 perf 或者 ebpf）來實現效能分析。

以 java 為例子，認識下 java 程式執行的程式碼結構 ，如下圖：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c9d43f9bad504768990368e5f63dfcec~tplv-k3u1fbpfcp-zoom-1.image "10.png")

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d4a6cbf3e944ed6812a6adddec7ed0c~tplv-k3u1fbpfcp-zoom-1.image "11.png")

對於 java 開發者而言，大部分場景是不考慮 JVM code，glibc code，kernel code 出問題的可能性的，這部分程式碼相對穩定，而且有穩定的組織去推動解決。因此 JVM Profiling 要表達的核心其實是：爬堆疊，只爬 Java code 這一層次（java stack），這個是大部分應用開發者關注的核心部分，對於下面的部分（native stack）則不在 java 開發者關心的範圍。

JVM 還有一個特徵，就是把 Linux 底層的概念遮蔽，替換成自己的概念體系，比如：

-   java 開發者更關心 java 執行緒狀態機而不是 JVM 程式的程式狀態機；
-   java 開發者更關心 java heap，stack，nio 等記憶體統計而不是 native heap，native stack 以及 rss，pagecache 的統計；
-   java 開發者關心 CMS 或 G1 垃圾回收情況而不是 Page Reclaim；
-   java 開發者更關心 synchronized，JUC 鎖，而不是 OS 鎖；

因此，JVM Profiling中的效能分析型別會更貼近 java 開發者的概念體系，而不是 system profile 關心的內容。

舉個例子，相較於 on-cpu profiling，作為 java 開發者，你是否會關心 JVM code 或者 glibc 是否存在問題，也許會，但是不可否認，這是非常少見的場景，更多關心的還是 Java code 這一層的問題，因此 JVM Profiling 的 cpu profiling 表達的是 **on-cpu profiling for java code。**

同理對於記憶體申請速率 alloc profiling：

-   system alloc profiling 關心的是使用者態記憶體分配器（malloc 分配器或者其他的）的分配速度；

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/74e34795cf1f463bba7f1a627686480c~tplv-k3u1fbpfcp-zoom-1.image "12.png")

-   JVM alloc profiling 關心的則是 TLAB 分配器的分配速度；

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/554b9b18c64b4bd0b60db31c881c8406~tplv-k3u1fbpfcp-zoom-1.image "13.png")

JVM Profiling 和 System profiling 關注點是有不同的：JVM Profiling 關注的是 JVM 上的效能，而不是貫穿從使用者態到核心態的整個流程，這是非常重要的一個區別，其他高階語言也是類似的情況。

-   **JVM Profiling Tools**

JAVA 社群有非常豐富的 JVM Profiling Tools：

-   Async-profiler **[** **4]** ：

-   -   jetbrains IntelliJ IDEA **[** **5]**
    -   alibaba Arthas

-   JProfiler
-   Honest profiler **[** **6]**
-   Uber JVM Profiler **[** **7]**
-   Fight Recorder **[** **8]**

-   -   JEP 349: JFR Event Streaming **[** **9]**

#### 1. JFR

JFR (Java Flight Recorder)是深度嵌入在 JVM 中的功能強大的應用問題診斷與效能剖析工具，在其低開銷的加持下，JFR 可在生產環境持續開啟。JFR 最開始是 JRockit 和 Oracle JDK 中的商業化特性，Oracle 在 Java 11 對其進行了開源。2019 年阿里巴巴作為主要貢獻者，聯合 Azul、Datadog、RedHat 等公司，一起將 JFR 移植進 OpenJDK 8 中。目前 Alibaba Dragonwell 8 和 11 中也包含完整的 JFR 功能。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a34da620c78341f48619762e0089752b~tplv-k3u1fbpfcp-zoom-1.image "14.png")

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9d1c5983a6854c329720f245d999d658~tplv-k3u1fbpfcp-zoom-1.image "15.png")

JFR 的事件包括下面幾類資訊：

1.  一般資訊：關於虛擬機器、作業系統和記錄的一般資訊；
1.  記憶體：關於記憶體管理和垃圾收集的資訊；
1.  程式碼：關於方法、異常錯誤、編譯和類載入的資訊；
1.  執行緒：關於應用程式和執行緒和鎖的資訊；
1.  I/O：關於檔案和套接字輸入、輸出的資訊；
1.  系統：關於正在執行 Java 虛擬機器的系統、程式和環境變數的資訊；
1.  型別：關於記錄中的事件型別的資訊。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1b1e8b37ede9481ba71529e6cb60dec6~tplv-k3u1fbpfcp-zoom-1.image "16.png")

透過 JFR 的 Event，可以覆蓋幾乎所有需要進行效能分析的場景:

-   on cpu profiling
-   alloc profiling
-   lock profiling
-   file read(write) profiling
-   socket read(write) profiling
-   ......

JFR 非常優秀，但是在國內環境，依然存在適配問題：

java 迭代速度太快了，java 已經發布了 17 了，但是國內不乏依舊跑在 java8 上的應用；而 JFR 從 11backport 到的最低版本是 8u272（8u262 只是有 JFR 的程式碼，但是不可用），這就導致了 8u272 之前的 java 沒辦法用 JFR；

JFR 本身也在發展迭代中，如 jdk.ObjectAllocationInNewTLAB。

jdk.ObjectAllocationOutsideTLAB 在 java16 之前的實現產生的 overhead 過高導致根本不適合在生產環境常態化採集；

#### 2. Async Profiler

組合使用 Perf_events 和 AsyncGetCallTrace 解決 JVM SafePoint Bias 問題，解決了 overhead 高問題。主流的 java IDE IntelliJ IDEA 和 alibaba 的 Arthas 提供的 profiling 能力透過 Async-profiler 實現的。因此 Arms 的方案裡面也藉助了這個工具。

## Arms Continuous JVM Profiler

為了更好的為使用者提供價值，Arms 聯合 Alibaba Dragonwell 團隊，基於業界主流設計，進行了深度最佳化，設計出了全新的採集、分析技術方案。其中採集方案兼顧效能和財務成本，優先使用更成熟和完善的 JFR，但在JFR是商業化特性的 OracleJDK 或 Async-Profiler 效能更優的情況下，採用 Async-Profiler 作為替代方案，並且是全自動的，使用者無需關注配置細節。

### Support list

-   **OpenJDK**

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9364d4829d1043258171eaf6c6f070dc~tplv-k3u1fbpfcp-zoom-1.image "17.png")

說明：

-   jdk8u272 以下的版本選擇 Async-Profilier 和核心原因是沒有 JFR 可用；
-   jdk8u272 之後直到 jdk16 之前，JFR 實現的 alloc 相關事件的開銷比較大，因此選擇 Async-Profilier；
-   其他情況，能用 JFR 都用 JFR

-   **Oracle JDK**

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f0fb950c182b480c82689d930ec8578b~tplv-k3u1fbpfcp-zoom-1.image "18.png")

說明：

-   OracleJDK8 上 JFR 是商業特性，因此選擇 Async-Profilier
-   OracleJDK11 之後的版本的 JFR 是開源特性，alloc 選擇 Async-Profilier 的原因一樣是因為 JFR 實現的 alloc 相關事件的開銷比較大，因此選擇 Async-Profilier
-   其他情況，能用 JFR 都用 JFR。

### 效能分析型別

目前 Arms 產品化部分包含 2 類 3 個效能分析型別，解決 java 開發者最常見的 CPU 和記憶體方面的問題：

-   CPU Time：全稱 On-CPU Profiling In Java Code，統計 java 程式碼佔用 CPU 時間；
-   Allocations：統計 TLAB 分配次數
-   Allocated Memory：統計 TLAB 分配記憶體總量，單位 bytes；

> 產品的 roadmap 中後續會考慮搞 lock，file，socket 等等效能分析的能力，這中間的主要核心考量是每一種實現對應的 overhead 評估和實現約束情況。

### OverHead

前文說過評價一款 Profiling Tools 是否適合上生產主要是看額外開銷是否足夠小，Arms 提供的能力整體依賴於 Async-profiler 以及 JFR，這兩個工具的開銷是關鍵：

-   Async-profiler：官方未給出資料性結論，只是說開銷很低；

-   JFR：按照預設配置，整體效能下降低於 2%。 **[** **10]**

因此 Async-profiler 和 Oracle 官方並沒有更細節的資料，因此我們實際在進行一些測試，供參考：

-   **壓力測試模型**

壓力測試模型如下圖示：

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ae63b4b1c23b4ee19006ed8140e119fc~tplv-k3u1fbpfcp-zoom-1.image "19.png")

測試程式碼包含資料庫查詢、JSON 序列化、日誌檔案順序寫、網路收發等。

-   **壓力測試客戶端**

使用 wrk 做併發測試，命令如下：

wrk -t2 -d 10 -c 10http://172.22.230.30:8088/queryRandom

客戶端的壓力的總體目標是把服務端的 CPU 壓力控制在 50%左右。壓力測試結果這裡評估對應用的影響主要透過 QPS（吞吐）和 RT（時延）作為標準（系統 CPU 壓力控制在 50%左右）：

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/41b5f2320c2549eeb088d4a9f2be76e9~tplv-k3u1fbpfcp-zoom-1.image "20.png")

> JFR Alloc 依賴的兩個 JFR Event 有非常嚴重的效能問題：1. jdk.ObjectAllocationInNewTLAB2. jdk.ObjectAllocationOutsideTLAB因此本測試不包含 JFR Alloc；JFR 的這個問題直到 JAVA15 以後才得到解決。

我們還做了一組極限壓測，將 CPU 全部打滿，這種情況的出的結論為 QPS 和 RT 的開銷低於 10%。這種極端情況也是存在，資料供參考。

### 最佳實踐路徑

-   **CPU 高排查路徑**

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/00b4898635124460b844b64e42a8f221~tplv-k3u1fbpfcp-zoom-1.image "21.png")

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8501284a7eef42f485a5ace5e79afe23~tplv-k3u1fbpfcp-zoom-1.image "22.png")

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ac829d09a9004941a06de59a8e56963d~tplv-k3u1fbpfcp-zoom-1.image "23.png")

**1. JVM 程式 CPU 高的傳統方式**

我們聚焦 User time 高的情況，java 開發者的排查流程：

1.定位 CPU 高的 java 程式的 pid，**top**；

2.定位具體執行緒 id，**top -p ${pid} -H**；

3.計算執行緒 ID 的 16 進位制值，**printf "%x\n" ${執行緒 ID}** ；

4.根據 stack trace，定位具體瓶頸點，**jstack ${pid}| grep ${執行緒 ID} -A 10**；

5.檢視 stack trace，識別程式碼，解決問題。

**2. 利用 Arms Continuous Java Profile 解決 JVM user 高的問題**

1. 確定是 JVM 業務程式導致 user CPU 升高；

![24.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/83a8869f6c8942a28c06cb1e47a82bb7~tplv-k3u1fbpfcp-zoom-1.image "24.png")

2. 找到 CPU 變高時間點，開啟火焰圖和人點方法統計，識別程式碼消耗，解決問題。

![25.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38f6a4f3da73468d83eb0cf98c63f3a0~tplv-k3u1fbpfcp-zoom-1.image "25.png")

直接定位到方法，並且把每個方法的耗時統計出來，如上圖左邊所示的熱點方法。過濾掉執行緒等相關條件（當 CPU 瓶頸是因為使用者程式碼導致的，開發者是不需要特別關心執行緒的，直接將所有執行緒中的 stack trace 全部進行統計彙總，然後按照每個方法的 Response time 進行彙總）。

-   **頻繁 GC**

第一步，開啟壓力程式，同時設定 heap 大小為 128M（-Xms128m-Xmx128m）

第二步，壓力程式的 gc 日誌部分如下圖，非常頻繁的進行 gc 操作；

```
85.013: [GC (Allocation Failure) [PSYoungGen: 29518K->3328K(36352K)] 47116K->21252K(123904K), 0.0065644 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
89.993: [GC (Allocation Failure) [PSYoungGen: 31736K->3328K(35840K)] 49660K->21260K(123392K), 0.0061679 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
94.062: [GC (Allocation Failure) [PSYoungGen: 31608K->3232K(36864K)] 49540K->21196K(124416K), 0.0070968 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
99.090: [GC (Allocation Failure) [PSYoungGen: 32934K->1344K(36864K)] 50898K->19332K(124416K), 0.0051987 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
103.114: [GC (Allocation Failure) [PSYoungGen: 29079K->2368K(37376K)] 47067K->20432K(124928K), 0.0056821 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
108.134: [GC (Allocation Failure) [PSYoungGen: 32528K->1344K(36864K)] 50592K->19464K(124416K), 0.0067361 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
113.086: [GC (Allocation Failure) [PSYoungGen: 31748K->3264K(37376K)] 49869K->21503K(124928K), 0.0059270 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
117.178: [GC (Allocation Failure) [PSYoungGen: 31709K->3328K(37376K)] 49948K->21591K(124928K), 0.0049904 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
121.192: [GC (Allocation Failure) [PSYoungGen: 32615K->3607K(37376K)] 50878K->21878K(124928K), 0.0076185 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
126.217: [GC (Allocation Failure) [PSYoungGen: 33278K->1312K(37376K)] 51549K->19615K(124928K), 0.0045188 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
131.159: [GC (Allocation Failure) [PSYoungGen: 32080K->3488K(37376K)] 50383K->21799K(124928K), 0.0046074 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
135.256: [GC (Allocation Failure) [PSYoungGen: 33274K->3488K(37376K)] 51585K->21807K(124928K), 0.0044789 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
140.276: [GC (Allocation Failure) [PSYoungGen: 33871K->1472K(37888K)] 52190K->19799K(125440K), 0.0043370 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
145.296: [GC (Allocation Failure) [PSYoungGen: 32925K->1472K(37888K)] 51252K->19799K(125440K), 0.0044817 secs] [Times: user=0.01 sys=0.01, real=0.00 secs]
150.321: [GC (Allocation Failure) [PSYoungGen: 32944K->1440K(37888K)] 51271K->19767K(125440K), 0.0041987 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
155.345: [GC (Allocation Failure) [PSYoungGen: 32896K->1472K(37888K)] 51223K->19799K(125440K), 0.0045417 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
160.374: [GC (Allocation Failure) [PSYoungGen: 33168K->1568K(37888K)] 51495K->19903K(125440K), 0.0051167 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
165.261: [GC (Allocation Failure) [PSYoungGen: 33469K->3616K(37888K)] 51804K->21959K(125440K), 0.0048307 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
170.286: [GC (Allocation Failure) [PSYoungGen: 35284K->3552K(37888K)] 53627K->21895K(125440K), 0.0143238 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
175.316: [GC (Allocation Failure) [PSYoungGen: 35008K->3584K(37888K)] 53351K->21927K(125440K), 0.0060600 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
180.338: [GC (Allocation Failure) [PSYoungGen: 35061K->3584K(37888K)] 53404K->21935K(125440K), 0.0044581 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
185.359: [GC (Allocation Failure) [PSYoungGen: 35044K->3584K(35840K)] 53395K->21935K(123392K), 0.0054453 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
190.384: [GC (Allocation Failure) [PSYoungGen: 35314K->3584K(37376K)] 53665K->21943K(124928K), 0.0050957 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
194.502: [GC (Allocation Failure) [PSYoungGen: 33085K->3584K(37376K)] 51444K->22007K(124928K), 0.0045832 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
199.526: [GC (Allocation Failure) [PSYoungGen: 33952K->1600K(37888K)] 52375K->20039K(125440K), 0.0051886 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
```

第三步，利用 Allocated  Memory 定位 collect-heap 記憶體是的主要申請是哪些方法：

![26.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0aefb756fa0448fab4bb02cf3430a67f~tplv-k3u1fbpfcp-zoom-1.image "26.png")

第四步，最佳化程式碼。

### Roadmap

1. 診斷型別增強；（file io，socket io，lock 等等）

2. 聚合能力增強；（merge 和 diff）

3. 查詢能力增強；（預處理能力，支援長時間聚合）

4. 火焰圖互動增強（StackFrame 表達更多含義，當前僅僅包含一個簡單字串）；

5. RPC tracing 和 profiling 聯動；

6. 多語言（其他高階語言適配）；

## *參考連結*

*[1] Google 論文：*

*<https:>*

*[2] golang內建pprof：*

*<https:>*

*[3] java11內建JFR：*

[*https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorde********* *********r.html#GUID-D38849B6-61C7-4ED6-A395-EA4BC32A9FD6*](https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorder.html#GUID-D38849B6-61C7-4ED6-A395-EA4BC32A9FD6)

*[4]* **Async-profiler*：*

*<https:>*

*[5] *jetbrains IntelliJ IDEA* ：*

*<https:>*

**[6]* Honest profiler*：

*<https:></https:>*

**[7]* Uber JVM Profiler*

*<https:>*

**[8]* Fight Recorder*

*<https:>*

**[9]* JEP 349: JFR Event Streaming*

*<https:>*

**[10]* JFR Overhead*

*<https:>*</https:></https:></https:></https:></https:></https:></https:></https:>

可觀測可回溯 | Continuous Profiling 實踐解析

相關文章