JMH簡介

本文由 ImportNew - hejiani 翻譯自
java-performance。

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

JMH的示例鏈接。

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

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

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

如何運行

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

<dependencies>
    <dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>0.4.2</version>
    </dependency>
</dependencies>

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

    Options opt = new OptionsBuilder()
                .include(".*" + YourClass.class.getSimpleName() + ".*")
                .forks(1)
                .build();
    new Runner(opt).run();

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

測試模式

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

時間單位

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

測試參數狀態

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

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

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

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

狀態設置和清理

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

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

冗余代碼

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

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

@GenerateMicroBenchmark
public void testSomething( BlackHole bh )
{
    bh.consume( Math.sin( state_field ));
    bh.consume( Math.cos( state_field ));
}

常量處理

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

private double x = Math.PI;

@GenerateMicroBenchmark
public void bhNotQuiteRight( BlackHole bh )
{
    bh.consume( Math.sin( Math.PI ));
    bh.consume( Math.cos( Math.PI ));
}

@GenerateMicroBenchmark
public void bhRight( BlackHole bh )
{
    bh.consume( Math.sin( x ));
    bh.consume( Math.cos( x ));
}

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

private double x = Math.PI;

@GenerateMicroBenchmark
public double testWrong()
{
    return Math.sin( Math.PI );
}

@GenerateMicroBenchmark
public double testRight()
{
    return Math.sin( x );
}

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

循環

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

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

分支

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

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

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

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

編譯器提示

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

注解控制測試

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

CPU消耗

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

多參數的測試運行

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

程序需要完成：

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

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

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

線程組——非統一的多線程

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

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

為設置測試組，需要：

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

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

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

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

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

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

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

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

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

總結

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