JMH是新的microbenchmark（微基準測試）框架（2013年首次發(fā)布）。與其他眾多框架相比它的特色優(yōu)勢在于，它是由Oracle實現(xiàn)JIT的相同人員開發(fā)的。特別是我想提一下Aleksey Shipilev和他優(yōu)秀的博客文章。JMH可能與最新的Oracle JRE同步，其結果可信度很高。

JMH的示例鏈接。

使用JMH僅需滿足2個必要條件(其他所有都是建議選項)：

• 設置jmh-core的maven依賴
• 使用@GenerateMicroBenchmark注解測試方法

本文將主要介紹JMH的基本規(guī)則和功能。第二篇文章將介紹JMH分析器。

如何運行

在pom文件中加入依賴(在Maven Central查看jmh-core的最新版本)：

生成一個包含main方法的Java類。main方法中加入以下代碼：

測試方法使用@GenerateMicroBenchmark注解。運行該類。

測試模式

測試方法上@BenchmarkMode注解表示使用特定的測試模式：

時間單位

使用@OutputTimeUnit指定時間單位，它需要一個標準Java類型java.util.concurrent.TimeUnit作為參數。可是如果在一個測試中指定了多種測試模式，給定的時間單位將用于所有的測試(比如，測試SampleTime適宜使用納秒，但是throughput使用更長的時間單位測量更合適)。

測試參數狀態(tài)

測試方法可能接收參數。這需要提供單個的參數類，這個類遵循以下4條規(guī)則：

• 有無參構造函數(默認構造函數)
• 是公共類
• 內部類應該是靜態(tài)的
• 該類必須使用@State注解

@State注解定義了給定類實例的可用范圍。JMH可以在多線程同時運行的環(huán)境測試，因此需要選擇正確的狀態(tài)。

除了將單獨的類標記@State，也可以將你自己的benchmark類使用@State標記。上面所有的規(guī)則對這種情況也適用。

狀態(tài)設置和清理

與JUnit測試類似，使用@Setup和@TearDown注解標記狀態(tài)類的方法(這些方法在JMH文檔中稱為fixtures)。setup/teardown方法的數量是任意的。這些方法不會影響測試時間(但是Level.Invocation可能影響測量精度)。

@Setup/@TearDown注解使用Level參數來指定何時調用fixture：

冗余代碼

冗余代碼消除是microbenchmark中眾所周知的問題。通常的解決方法是以某種方式使用計算結果。JMH本身不會實施對冗余代碼的消除。但是如果你想消除冗余代碼——要做到測試程序返回值不為void。永遠返回你的計算結果。JMH將完成剩余的工作。

如果測試程序需要返回多個值，將所有這些返回值使用省時操作結合起來(省時是指相對于獲取到所有結果所做操作的開銷)，或者使用BlackHole作為方法參數，將所有的結果放入其中(注意某些情況下BlockHole.consume可能比手動將結果組合起來開銷更大)。BlackHole是一個thread-scoped類：

常量處理

如果計算結果是可預見的并且不依賴于狀態(tài)對象，它可能被JIT優(yōu)化。因此，最好總是從狀態(tài)對象讀取測試的輸入并且返回計算的結果。這條規(guī)則大體上用于單個返回值的情形。使用BlackHole對象JVM更難優(yōu)化它(但不是不可能被優(yōu)化)。下面測試的所有方法都不會被優(yōu)化：

返回單個值的情形更加復雜。下面的測試不會被優(yōu)化，但是如果使用Math.log替換Math.sin，那么testWrong方法將被常量值替換。

因此，為使測試更可靠要嚴格遵守以下規(guī)則：永遠從狀態(tài)對象讀取測試輸入并返回計算的結果。

循環(huán)

不要在測試中使用循環(huán)。JIT非常聰明，在循環(huán)中經常出現(xiàn)不可預料的處理。要測試真實的計算，讓JMH處理剩余的部分。

在非統(tǒng)一開銷操作情況下(比如測試處理列表的時間，這個列表在每個測試后有所增加)，你可能使用@BenchmarkMode(Mode.SingleShotTime) 和@Measurement(batchSize = N)。但是不允許你自己實現(xiàn)測試的循環(huán)。

分支

默認JMH為每個試驗(迭代集合)fork一個新的java進程。這樣可以防止前面收集的“資料”——其他被加載類以及它們執(zhí)行的信息對當前測試的影響。比如，實現(xiàn)了相同接口的兩個類，測試它們的性能，那么第一個實現(xiàn)(目標測試類)可能比第二個快，因為JIT發(fā)現(xiàn)第二個實現(xiàn)類后就把第一個實現(xiàn)的直接方法調用替換為接口方法調用。

因此，不要把forks設為0，除非你清楚這樣做的目的。

極少數情況下需要指定JVM分支數量時，使用@Fork對方法注解，就可以設置分支數量，預熱(warmup)迭代數量和JVM分支的其他參數。

可能通過JMH API調用來指定JVM分支參數也有優(yōu)勢——可以使用一些JVM -XX:參數，通過JMH API訪問不到它。這樣就可以根據你的代碼自動選擇最佳的JVM設置(new Runner(opt).run()以簡便的形式返回了所有的測試結果)。

編譯器提示

可以為JIT提供關于如何使用測試程序中任何方法的提示。“任何方法”是指任何的方法——不僅僅是@GenerateMicroBenchmark注解的方法。使用@CompilerControl模式(還有更多模式，但是我不確定它們的有用程度)：

注解控制測試

通過注解指定JMH參數。這些注解用在類或者方法上。方法注解總是優(yōu)先于類的注解。

CPU消耗

有時測試消耗一定CPU周期。通過靜態(tài)的BlackHole.consumeCPU(tokens)方法來實現(xiàn)。Token是一些CPU指令。這樣編寫方法代碼就可以達到運行時間依賴于該參數的目的(不被任何JIT/CPU優(yōu)化)。

多參數的測試運行

很多情況下測試代碼包含多個參數集合。幸運的是，要測試不同參數集合時JMH不會要求寫多個測試方法。或者準確來說，測試參數是基本類型，基本包裝類型或者String時，JMH提供了解決方法。

程序需要完成：

1. 定義@State對象
2. 在其中定義所有的參數字段
3. 每個字段都使用@Param注解

@Param注解使用String數組作為參數。這些字符串在任何@Setup方法被調用前轉換為字段類型。然而，JMH文檔中聲稱這些字段值在@Setup方法中不能被訪問。

JMH使用所有@Param字段的輸出結果。因此，如果第一個字段有2個參數，第二個字段有5個參數，測試將運行2 * 5 * Forks次。

線程組——非統(tǒng)一的多線程

我們已經提到@State(Scope.Benchmark)用來測試多線程訪問狀態(tài)對象的情形。并發(fā)程度通過用來測試的線程數量設置。

可能也需要定義對狀態(tài)對象非統(tǒng)一訪問的情況——比如測試“讀取——寫入”場景時，讀線程數通常高于寫線程數量。JMH使用線程組來應對這種情形。

為設置測試組，需要：

1. 使用@Group(name)注解標記所有的測試方法，為同一個組中的所有測試設置相同的名稱(否則這些測試將獨立運行——沒有任何警告提示！)
2. 使用@GroupThreads(threadsNumber)注解標記每個測試，指定運行給定方法的線程數量。

JMH將啟動給定組的所有@GroupThreads，并發(fā)運行相同實驗中同一組的所有測試。組和每個方法的結果將單獨給出。

多線程——偽共享字段訪問

你可能知道這樣一個事實，大多數現(xiàn)代x86 CPU有64字節(jié)的cache line(緩存行)。CPU緩存提高了數據讀取速率，但同時，如果你需要從多個線程同時讀寫兩個鄰近的字段，也會產生性能瓶頸。這種情況稱為“偽共享”——字段似乎是獨立訪問的，但是實際上它們在硬件層面的相互競爭。

這個問題通常的解決方案是兩邊都增加至少128字節(jié)的虛擬數據。因為JVM可以將類的字段重排序，在相同的類內部增加可能不能正確運行。

更加健壯的方法是使用類層次——JVM通常將屬于同一個類的字段放在一起。比如，定義類A有一個只讀字段，類B繼承類A且定義16個long字段，類C繼承類B定義可寫字段，最后類D繼承類C定義另一個16個long字段——這就防止了被分配在下一個內存中對象的寫變量競爭。

以防讀寫的字段類型相同，也可以使用兩個數據位置相互距離很遠的稀疏數組。在前面的情況中不要使用數組——它們是對象特定類型，僅需要增加4或8字節(jié)(取決于JVM設置)。

這個問題的另一種解決方法是如果你已經用到了Java 8：在可寫字段上使用@sun.misc.Contended以及-XX:-RestrictContended的JVM設置。更多細節(jié)，參見Aleksey Shipilev的說明。

JMH是如何解決競爭字段訪問的呢？它在兩邊都增加了@State對象，但是這并不能在單一對象內部對個別的字段增加——需要自己來處理。

總結

• JMH用于各種類型的microbenchmark——每個測試從納秒到毫秒。它關注所有可測量的邏輯，測試人員只需編寫測試方法的任務代碼。JMH也包含對所有類型多線程測試的內在支持——統(tǒng)一(所有線程運行相同代碼)和非統(tǒng)一(線程分組，每個組運行自己的代碼)。
• 如果僅僅一條規(guī)則需要記住的話，那就是——永遠從@State對象讀取測試輸入并返回計算的結果(無論結果是明確的還是通過 BlackHole對象返回)。