提到飛行記錄器，或許你的腦海中并未立刻浮現出清晰的畫面，但一說起“黑匣子”，想必大多數人都能恍然大悟，知曉其重要性及用途。在航空領域，黑匣子作為不可或缺的設備，默默記錄著飛行過程中的每一項關鍵數據，從飛行高度、速度到機艙內的對話，無一遺漏。一旦飛機發生事故，這些珍貴的數據便成為調查人員還原事件真相、精準定位事故原因的寶貴線索。
同樣地，在軟件開發的世界里，也有這樣一個“黑匣子”般的存在——Java飛行記錄器（Java Flight Recorder，簡稱JFR）。它借鑒了航空黑匣子的設計理念，卻應用于一個截然不同的領域：Java應用程序的性能分析與故障排查。
一、 背景與概述
1.1 JFR 簡介
Java Flight Recorder (JFR) 是 Oracle JDK 內置的性能分析工具，用于監控 JVM 和 Java 應用程序的運行時行為。其特點包括：
- 低開銷：生產環境中通常僅產生
1%左右的性能損耗 - 實時監控：可記錄 JVM 事件、方法調用、內存分配等詳細信息、支持動態啟停記錄
- 事件驅動：捕獲超過 200 種不同類型的事件（JDK 11+）
- 集成分析：與 Java Mission Control (JMC) 工具深度集成
Java飛行記錄器（Java Flight Recorder，JFR）是JVM內置的低開銷性能分析和故障排查工具，用于記錄Java應用程序運行時的詳細數據，類似飛機的“黑匣子”。它通過事件機制采集JVM和應用程序的運行時信息，包括CPU、內存、線程、垃圾回收（GC）、鎖競爭等數據，幫助開發者定位性能瓶頸和異常問題。
📌 適用場景：性能調優、內存泄漏排查、高 CPU 使用率分析等
1.2. JFR 的發展歷史
1.2.1. 關鍵里程碑
- JRockit Flight Recorder：JFR 最初是由 BEA Systems 開發的 JRockit JVM的一部分，當時被稱為 JRockit Flight Recorder。
- Oracle 收購 Sun Microsystems：隨著 Oracle 收購了 Sun Microsystems（Java的原始開發者）以及 BEA Systems，JFR 被集成到了 HotSpot JVM 中，并從 JDK 7u40 和 JDK 8u40開始被包含進去。此時，JFR 還是一個商業特性，需要許可證才能在生產環境中使用。
- JDK 11：JFR 2.0版本發布，提供了更豐富的功能集。JFR 成為了 OpenJDK 的一部分，無需額外安裝。作為一個開源項目，不再需要商業許可證即可使用。
- JDK 14：引入了 JFR Event Streaming，允許實時處理 JFR 事件。
- JDK 17：穩定支持虛擬線程事件，并增強云原生環境兼容性。
1.2.2. Java Flight Recorder (JFR) 版本變化
| JDK版本 | 發布日期 | 主要變化與新特性 |
|---|---|---|
| JDK 7u40 | 2013年9月 | - JFR首次在Oracle JDK中作為商業特性引入 - 提供基本的事件記錄功能，如GC、線程等 - JCMD控制 |
| JDK 8u40 | 2015年3月 | - 增加了更多的內置事件類型 - 改善了性能開銷，減少了對應用程序的影響 -JMX動態控制 |
| JDK 9 | 2017年9月 | - 開始支持自定義事件 - 引入了更豐富的API用于編程控制JFR會話 |
| JDK 11 | 2018年9月 | - JFR成為OpenJDK的一部分（JEP 328） - JFR 2.0 版本、完全開源，社區可以貢獻代碼 - 支持JIT編譯器事件，記錄編譯器活動和性能數據 - 對容器環境的支持，更好地適應Docker等容器化部署 - 改進了數據格式和壓縮算法，提高了存儲效率 |
| JDK 13 | 2019年9月 | - 引入了jdk.jfr.consumer模塊，允許程序化地讀取和分析JFR文件- 增強了事件過濾和配置選項 |
| JDK 14 | 2020年3月 | - 添加了對虛擬線程的支持（實驗性） - 改進了事件元數據的可讀性和靈活性 |
| JDK 15 | 2020年9月 | - 引入了新的事件類別，如jdk.VirtualThread*- 改進了JFR與容器環境的兼容性 |
| JDK 16 | 2021年3月 | - 支持動態調整采樣率 - 增強了對云原生環境的支持 |
| JDK 17 | 2021年9月 | - 穩定版支持虛擬線程事件 - 改進了與Kubernetes等平臺的集成 - 增強了安全性，包括對敏感數據的保護 |
| JDK 18 | 2022年3月 | - 引入了對GraalVM Native Image的支持 - 改進了內存管理和垃圾回收事件的詳細程度 |
| JDK 19 | 2022年9月 | - 增強了對多租戶環境的支持 - 改進了事件的時間戳精度 |
| JDK 20 | 2023年3月 | - 引入了新的事件類型，如jdk.CodeCacheFlush- 改進了對異步事件的支持 |
| JDK 21 | 2023年9月 | - 進一步增強了對虛擬線程的支持 - 改進了與Spring Boot等框架的集成 |
二、啟用 JFR
2.1. 通過命令行參數啟動
# JDK 8 需要添加以下參數，解鎖商業功能
java -XX:+UnlockCommercialFeatures -XX:+FlightRecorder ...# JDK 11+ 開源版本直接啟用
java -XX:StartFlightRecording:delay=5s,duration=60s,name=MyRecording,filename=recording.jfr ...
常用選項：
filename=recording.jfr：指定輸出文件名duration=60s：設置錄制時長delay=10s：延遲啟動時間settings=profile：使用預定義配置文件（如profile,default)name=MyRecording：為錄制會話命名
2.2. 運行時觸發，使用jcmd工具
jcmd <PID> JFR.start duration=60s filename=recording.jfr
jcmd <PID> JFR.dump filename=partial.jfr
jcmd <PID> JFR.stop
2.3. 通過JMC（JDK Mission Control）啟動
操作步驟：
- 打開JMC工具。
- 連接到正在運行的JVM實例。
- 在左側導航欄選擇“Flight Recorder”。
- 配置錄制設置（如持續時間、事件類型等）。
- 點擊“Start Recording”。
2.4 通過Spring Boot Actuator集成啟動
2.4.1. 添加依賴
在pom.xml中添加依賴：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-actuator</artifactId>
</dependency>
2.4.2. 使用HTTP接口啟動
curl -X POST http://localhost:8080/actuator/jfr/start
curl -X POST http://localhost:8080/actuator/jfr/dump?filename=myapp_recording.jfr
curl -X POST http://localhost:8080/actuator/jfr/stop
三、JFR 事件
在 JFR中，一切皆為 Event！JFR 事件是 JFR 捕獲和記錄的最小數據單元，每個事件都代表了在特定時間點上系統或應用某個方面的信息。每條事件記錄包含了多個數據字段，如時間戳、事件持續時間、以及其他與業務或系統狀態相關的元數據。大部分的 Event，都有 Event 是在哪個線程發生的，Event 發生的時候這個線程的調用棧，Event 的持續時間。這就非常有用了，利用這些信息，我們可以回溯 Event 發生當時的情況。
3.1. 按來源分類
| 類別 | 說明 | 示例事件 |
|---|---|---|
| JVM 事件 | JVM 內部操作產生的事件 | jdk.GarbageCollection, jdk.JITCompilation |
| JDK 庫事件 | JDK 類庫（如 I/O、網絡、集合）觸發的事件 | jdk.FileRead, jdk.SocketWrite |
| OS 事件 | 操作系統級別的資源監控數據 | jdk.CPULoad, jdk.PhysicalMemory |
| 自定義事件 | 開發者定義的應用層事件 | com.example.OrderProcessEvent |
3.2. 按觸發方式分類
- 閾值觸發事件：當指標超過預設閾值時記錄（如
jdk.CPULoad） - 周期采樣事件：按固定時間間隔采集（如
jdk.ThreadAllocationStatistics） - 即時觸發事件：特定操作發生時立即記錄（如
jdk.ExceptionThrown）
3.3、關鍵內置事件
3.3.1. 垃圾回收相關
| 事件名稱 | 作用 |
|---|---|
jdk.GarbageCollection | 記錄 GC 暫停時間和原因（Young GC/Full GC） |
jdk.OldObjectSample | 跟蹤可能引發內存泄漏的舊對象（需啟用 -XX:StartFlightRecording=old-object-queue-size=256） |
3.3.2. 線程與鎖
| 事件名稱 | 作用 |
|---|---|
jdk.ThreadSleep | 記錄線程睡眠時間 |
jdk.JavaMonitorWait | 監控 synchronized 鎖等待時間 |
jdk.ThreadPark | 跟蹤 LockSupport.park() 調用（如 AQS 鎖） |
3.3.3. 異常與錯誤
| 事件名稱 | 作用 |
|---|---|
jdk.ExceptionThrown | 記錄所有異常拋出事件（包括堆棧跟蹤） |
jdk.ErrorThrown | 記錄嚴重錯誤事件（如 OutOfMemoryError） |
3.3.4. I/O 與網絡
| 事件名稱 | 作用 |
|---|---|
jdk.FileRead | 跟蹤文件讀取操作（包含路徑和耗時） |
jdk.SocketRead | 記錄 Socket 讀取數據量及延遲 |
3.3.5. JIT 與類加載
| 事件名稱 | 作用 |
|---|---|
jdk.JITCompilation | 記錄方法編譯耗時和優化級別 |
jdk.ClassLoad | 跟蹤類加載過程及耗時 |
3.4. 多線程低開銷設計與異步存儲原理
3.4.1. 事件產生與多線程協作
- 多線程事件觸發：
JFR 事件由業務線程在執行過程中主動生成（如方法調用、異常拋出、鎖競爭等），每個線程獨立維護線程本地緩沖區（Thread Local Buffer），直接以二進制格式緩存事件流。 - 線程隔離與無鎖設計：
各線程僅操作自身緩沖區，避免全局鎖競爭，確保事件記錄低延遲（通常低于微秒級）。
3.4.2. 分級緩沖存儲流程
-
線程本地緩沖區（Thread Local Buffer）
- 默認容量約 34KB，采用循環隊列結構存儲二進制事件數據。
- 緩沖區滿時觸發異步刷寫（非阻塞），將數據批量推送至全局緩沖區。
-
全局緩沖區（Global Buffer）與持久化
- 全局緩沖區整合多線程事件流，由獨立的
jfr守護線程負責管理。 - 后臺線程將全局緩沖區的數據異步寫入磁盤（生成
.jfr文件），完全分離業務線程與I/O操作，避免阻塞主邏輯。
- 全局緩沖區整合多線程事件流，由獨立的
3.4.3. 高效性核心設計
- 二進制直接存儲：
事件以二進制格式在內存中流轉，跳過多余的序列化/反序列化步驟，減少 CPU 開銷。 - 異步分層處理：
業務線程僅負責生成事件，緩沖區刷寫與持久化由獨立線程完成，通過批量合并降低 I/O 頻率。 - 動態采樣與可控開銷：
JFR 支持按需配置采樣率（如-XX:FlightRecorderOptions=stackdepth=128），通過 JVM 內部 Hook 實現非侵入式監控，無需代碼插樁。
3.4.4. 自定義事件對業務的影響
- 輕量級托管機制：
開發者通過繼承jdk.jfr.Event定義的事件，由 JFR 框架統一管理。調用commit()方法時，事件僅寫入線程本地緩沖區，不占用業務線程額外時間。 - 背壓（Backpressure）保護：
若事件產生速率超過持久化能力（如高頻自定義事件），JFR 會觸發背壓機制，選擇性丟棄低優先級事件或限制事件生成，防止資源耗盡。 - 可控的性能損耗：
合理使用自定義事件（如避免每秒超 10 萬次高頻提交），對業務延遲的影響通常可控制在 1%~2% 以內，極端場景需結合采樣策略優化。
四、自定義事件開發
4.1. 自定義事件開發價值
通過自定義JFR事件，開發者可以：
- 業務指標可視化：記錄訂單創建、支付處理等關鍵業務指標
- 精準性能分析：追蹤特定方法執行耗時、資源消耗
- 上下文關聯：將JVM事件與業務邏輯關聯分析
- 生產環境診斷：低開銷實時監控生產系統
4.2. 自定義事件開發四部曲
4.2.1. 定義事件類
@Name("com.example.OrderCreated")
@Label("Order Created Event")
@Category("Business")
@Description("Records order creation information")
public class OrderCreatedEvent extends Event {@Label("Order ID")public String orderId;@Label("Total Amount")@Amount(Currency.CNY)public double amount;@Label("User Type")public UserType userType;@Label("Creation Duration")@Timespan(Timespan.MILLISECONDS)public long duration;
}
注解說明：
@Name: 定義事件的全局唯一標識符，推薦使用反向域名命名法（類似Java包名），避免與JVM內置事件沖突。@Label: 事件名稱，在JMC等可視化工具中作為顯示名稱。@Category: JMC中的分類顯示，在JMC左側導航樹狀呈現。@Description: 提供事件的詳細文檔說明嗎，在JMC中通過"Show Description"查看。
4.2.2. 觸發事件記錄
public class OrderService {public void createOrder(OrderRequest request) {OrderCreatedEvent event = new OrderCreatedEvent();if (event.isEnabled()) {long start = System.nanoTime();// 業務邏輯執行...event.orderId = generatedId;event.amount = calculateAmount();event.userType = getCurrentUserType();event.duration = (System.nanoTime() - start) / 1_000_000;event.commit();}}
}
4.2.2. 事件注冊與啟用
@Registered(true)
public class OrderCreatedEvent extends Event {//...
}
動態啟用配置：
jcmd <PID> JFR.configure threshold=10ms stacktrace=true path-to-gc-roots=true
4.2.4. 事件數據分析
使用JMC分析：
public static void analyzeJfr(File recordingFile) throws IOException {try (RecordingStream rs = new RecordingStream(recordingFile)) {rs.onEvent("com.example.OrderCreated", event -> {System.out.printf("訂單%s 金額%.2f 耗時%dms%n",event.getString("orderId"),event.getDouble("amount"),event.getLong("duration"));});rs.start();}
}
五、高級技巧
5.1 異步事件處理
@Async
public class AsyncPaymentEvent extends Event {//...
}
5.2 閾值控制
@Threshold("20 ms")
public class SlowMethodEvent extends Event {//...
}
5.3 自定義轉換器
public class UserTypeConverter extends Converter<UserType> {public String toString(UserType type) {return type.name().toLowerCase();}
}public class OrderCreatedEvent extends Event {@Converter(UserTypeConverter.class)public UserType userType;
}
六、總結
通過自定義JFR事件，開發者可以獲得：
- 生產環境細粒度監控能力
- 業務與JVM事件的關聯分析
- 傳統日志無法實現的性能洞察
建議結合JMC可視化工具和jfr命令行工具，構建完整的性能監控體系。下一篇來具體介紹使用JMC進行JFR性能分析指南。
最佳實踐：從關鍵業務路徑開始逐步增加事件埋點，通過持續的性能分析迭代優化事件配置。
——Brick_Breaker詳細制作全流程)
