1. 性能分析工具
1.1. 必須有足夠大的堆來處理資料
1.2. 運行性能分析工具時開啟并發GC演算法
1.3. 不合時宜的Full GC暫停會導致緩沖區的資料溢位
1.4. 性能分析的一個缺陷就是在應用程式中引入測驗會改變其性能
1.5. 在作業時要“附加”到被分析的應用程式上
-
1.5.1. 通過socket或者被稱為JVM工具介面（JVM Tool Interface，JVMTI）的原生Java介面進行的
-
1.5.2. 目標應用程式和性能分析工具開始交換關于目標應用程式行為的資訊
2. 采樣分析器
2.1. 性能分析的基本模式
2.2. 想要減小誤差，就要延長采樣周期并減小采樣間隔
2.3. 安全點偏差（safepoint bias）
- 2.3.1. 只有在執行緒到安全點之后才可以獲取執行緒的堆疊軌跡（stack trace）
2.4. 執行緒自動進入安全點場景
-
2.4.1. 在同步鎖上阻塞
-
2.4.2. 等待I/O時阻塞
-
2.4.3. 等待管程時阻塞
-
2.4.4. 執行緒掛起
-
2.4.5. 正在執行Java本地介面（Java Native Interface，JNI）代碼（執行GC鎖定函式除外）
2.5. 異步分析器（async profiler）
-
2.5.1. JVM可以在任何時間點提供堆疊資訊，而無須等待執行緒到達（同步）安全點
-
2.5.2. 通過AsyncGetCallTrace介面實作的
-
2.5.3. 異步介面在Java 8被公開，在此之前它是私有介面
-
2.5.4. 以異步方式收集堆疊資訊的采樣分析器引入的測量失真更小
2.6. 火焰圖（?ame graph）
-
2.6.1. 一個應用程式呼叫堆疊的互動式圖表
-
2.6.2. 自底向上的圖表
-
2.6.3. 開源專案async-profiler
2.7. 自頂向下的呼叫樹（call tree）
3. 探查分析器
3.1. 相對于采樣分析器更有侵入性
- 3.1.1. 會在類加載時更改位元組碼序列
3.2. 能提供更多關于應用程式內部正在發生什么的有益資訊
3.3. 更可能在應用程式中引入性能偏差
- 3.3.1. 編譯器是基于代碼的大小來決定是否行內的，而根據代碼探查的方式，方法可能不再符合行內的條件
3.4. 最好用于二級分析
-
3.4.1. 采樣分析器將性能問題指向某個包或某段代碼，然后探查分析器在需要時深入研究此代碼
-
3.4.2. 用于探查一小部分代碼——幾個類或包
4. 阻塞方法和執行緒時間線
4.1. 要知道執行緒阻塞是不是性能問題的原因，需要檢查它們為什么被阻塞
4.2. 通過正在阻塞的方法或者執行緒時間線分析，可以分辨阻塞的執行緒
5. 原生分析器
5.1. async-profiler和Oracle Developer Studio的工具
5.2. 可以提供JVM代碼和應用程式代碼的內部運行資訊
5.3. 如果原生分析器顯示主要占用CPU資源的是GC時間，那么優化垃圾回收器是正確的選擇
5.4. 如果它顯示編譯執行緒占用大量時間，那么這通常不會影回應用程式的性能
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/547479.html
標籤：其他