1. 理解可變性

1.1. 理解測試結果如何隨時間變化

1.2. 可以通過多次運行測試後取平均值來解決

1.3. 因代碼改進而進行的測試叫作回歸測試（regression testing）

• 1.3.1. 原本的代碼叫作基線（baseline）

• 1.3.2. 新的代碼叫作樣本（specimen）

1.4. 結果的變化越大，越難判斷平均值的差異是由於真正的性能問題還是隨機變化

1.5. 正確判斷兩個測試的結果是否有差異需要進行一定程度的統計分析，以確保感知到的差異不是隨機波動造成的

• 1.5.1. 要進行嚴謹的統計分析，可以使用T檢驗比較測試結果

• 1.5.2. 檢驗的結果表示出現性能倒退的概率，但是它並不能顯示出哪些倒退應該忽略，哪些應該追蹤。在這兩者間找到平衡是一種性能工程藝術

2. 早測試、常測試

2.1. 性能測試作為開發周期中的必要部分

2.2. 早期測試帶來的問題

• 2.2.1. 受發佈時間的限制，開發人員需要儘快檢入代碼

• 2.2.2. 代碼的性能特征會隨著代碼的變化而變化

2.3. 自動化一切

• 2.3.1. 所有的性能測試都應該腳本化（或者程式化，不過腳本化通常更容易）

2.4. 測量一切

• 2.4.1. 自動化必須收集可以想到的每一份數據，以便用於以後的分析

2.5. 在目標系統上運行

• 2.5.1. 很多重要的調優標誌會基於JVM運行的底層硬體系統，計算出它們的預設值

• 2.5.2. 不同平臺的代碼編譯方式不同

• 2.5.3. 軟體緩存和更重要的硬體緩存，在不同的系統和不同的負載下的表現也不同

3. jmh提供微基準測試

3.1. 適用於納（nano）/微（micro）/毫（milli）/巨集（macro）等規模的基準測試

3.2. 隨著Java 9一起發佈的

• 3.2.1. 組成jmh的類庫相容JDK 8及之後的版本

• 3.2.2. 並沒有與任何具體的Java版本綁定

• 3.2.3. JDK中沒有支持jmh的工具

3.3. Blackhole類是jmh的特性

• 3.3.1. 解決了微基準測試的一個重要問題：如果一個操作的值沒有用到，那麼編譯器會直接優化這個操作

• 3.3.2. 所以把值傳遞給Blackhole的consume()方法可以確保值被使用

3.4. Setup註解的Level值

• 3.4.1. Level.Trial

  • 3.4.1.1. 在基準測試代碼初始化時執行一次

• 3.4.2. Level.Iteration

  • 3.4.2.1. 在基準測試每次迭代前完成（每個測量期）

• 3.4.3. Level.Invocation

  • 3.4.3.1. 在每次測試方法執行之前完成

3.5. -f 5

• 3.5.1. 派生試驗的運行次數（預設為5）

3.6. -wi 5

• 3.6.1. 每次試驗的預熱迭代次數（預設為5）

3.7. -i 5

• 3.7.1. 每次試驗的測量迭代次數（預設為5）

3.8. -r 10

• 3.8.1. 每次迭代的最少時間（以秒為單位）

• 3.8.2. 迭代的時間可能比這個時間長，具體取決於目標方法的實際執行時間

3.9. 對於更穩定的測試，降低這些參數的值一般可以縮短運行測試所需的時間

3.10. 通常讓Java代碼變得更好、更快的方法是寫出更好的演算法，但這個實現與任何Java調優實踐或者Java編碼實踐無關