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

JMH的示例鏈接。

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

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

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

如何運(yùn)行

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

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

測(cè)試方法使用@GenerateMicroBenchmark注解。運(yùn)行該類。

測(cè)試模式

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

時(shí)間單位

使用@OutputTimeUnit指定時(shí)間單位，它需要一個(gè)標(biāo)準(zhǔn)Java類型java.util.concurrent.TimeUnit作為參數(shù)?？墒侨绻谝粋€(gè)測(cè)試中指定了多種測(cè)試模式，給定的時(shí)間單位將用于所有的測(cè)試(比如，測(cè)試SampleTime適宜使用納秒，但是throughput使用更長(zhǎng)的時(shí)間單位測(cè)量更合適)。

測(cè)試參數(shù)狀態(tài)

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

• 有無參構(gòu)造函數(shù)(默認(rèn)構(gòu)造函數(shù))
• 是公共類
• 內(nèi)部類應(yīng)該是靜態(tài)的
• 該類必須使用@State注解

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

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

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

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

@Setup/@TearDown注解使用Level參數(shù)來指定何時(shí)調(diào)用fixture：

冗余代碼

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

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

常量處理

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

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

因此，為使測(cè)試更可靠要嚴(yán)格遵守以下規(guī)則：永遠(yuǎn)從狀態(tài)對(duì)象讀取測(cè)試輸入并返回計(jì)算的結(jié)果。

循環(huán)

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

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

分支

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

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

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

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

編譯器提示

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

注解控制測(cè)試

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

CPU消耗

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

多參數(shù)的測(cè)試運(yùn)行

很多情況下測(cè)試代碼包含多個(gè)參數(shù)集合。幸運(yùn)的是，要測(cè)試不同參數(shù)集合時(shí)JMH不會(huì)要求寫多個(gè)測(cè)試方法。或者準(zhǔn)確來說，測(cè)試參數(shù)是基本類型，基本包裝類型或者String時(shí)，JMH提供了解決方法。

程序需要完成：

1. 定義@State對(duì)象
2. 在其中定義所有的參數(shù)字段
3. 每個(gè)字段都使用@Param注解

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

JMH使用所有@Param字段的輸出結(jié)果。因此，如果第一個(gè)字段有2個(gè)參數(shù)，第二個(gè)字段有5個(gè)參數(shù)，測(cè)試將運(yùn)行2 * 5 * Forks次。

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

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

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

為設(shè)置測(cè)試組，需要：

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

JMH將啟動(dòng)給定組的所有@GroupThreads，并發(fā)運(yùn)行相同實(shí)驗(yàn)中同一組的所有測(cè)試。組和每個(gè)方法的結(jié)果將單獨(dú)給出。

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

你可能知道這樣一個(gè)事實(shí)，大多數(shù)現(xiàn)代x86 CPU有64字節(jié)的cache line(緩存行)。CPU緩存提高了數(shù)據(jù)讀取速率，但同時(shí)，如果你需要從多個(gè)線程同時(shí)讀寫兩個(gè)鄰近的字段，也會(huì)產(chǎn)生性能瓶頸。這種情況稱為“偽共享”——字段似乎是獨(dú)立訪問的，但是實(shí)際上它們?cè)谟布用娴南嗷ジ?jìng)爭(zhēng)。

這個(gè)問題通常的解決方案是兩邊都增加至少128字節(jié)的虛擬數(shù)據(jù)。因?yàn)镴VM可以將類的字段重排序，在相同的類內(nèi)部增加可能不能正確運(yùn)行。

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

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

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

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

總結(jié)

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