使用JMH做Java微基準測試使用JMH做Java微基準測試

       在使用Java程式設計過程中，我們對于一些代碼調用的細節有多種編寫方式，但是不确定它們性能時，往往采用重複多次計數的方式來解決。但是随着JVM不斷的進化，随着代碼執行次數的增加，JVM會不斷的進行編譯優化，使得重複多少次才能夠得到一個穩定的測試結果變得讓人疑惑，這時候有經驗的同學就會在測試執行前先循環上萬次并注釋為預熱。

       沒錯！這樣做确實可以獲得一個偏向正确的測試結果，但是我們試想如果每到需要斟酌性能的時候，都要根據場景寫一段預熱的邏輯嗎？當預熱完成後，需要多少次疊代來進行正式内容的測量呢？每次測試結果的輸出報告是不是都需要用<code>System.out</code>來輸出呢？

       其實這些工作都可以交給 JMH (the Java Microbenchmark Harness) ，它被作為Java9的一部分來釋出，但是我們完全不需要等待Java9，而可以友善的使用它來簡化我們測試，它能夠照看好JVM的預熱、代碼優化，讓你的測試過程變得更加簡單。

       首先在項目中新增依賴，<code>jmh-core</code>以及<code>jmh-generator-annprocess</code>的依賴可以在maven倉庫中找尋最新版本。

       建立一個<code>Helloworld</code>類，裡面隻有一個空方法<code>m()</code>，标注了<code>@Benchmark</code>的注解，聲明這個方法為一個微基準測試方法，JMH 會在編譯期生成基準測試的代碼，并運作它。

       接着添加一個main入口，由它來啟動測試。

       簡單介紹一下這個<code>HelloworldRunner</code>，它是一個入口的同時還完成了 JMH 測試的配置工作。預設場景下，JMH 會找尋标注了<code>@Benchmark</code>類型的方法，可能會跑一些你所不需要的測試，這樣就需要通過<code>include</code>和<code>exclude</code>兩個方法來完成包含以及排除的語義。

       <code>warmupIterations(10)</code>的意思是預熱做10輪，<code>measurementIterations(10)</code>代表正式計量測試做10輪，而每次都是先執行完預熱再執行正式計量，内容都是調用标注了<code>@Benchmark</code>的代碼。

       <code>forks(3)</code>指的是做3輪測試，因為一次測試無法有效的代表結果，是以通過3輪測試較為全面的測試，而每一輪都是先預熱，再正式計量。

       我們運作<code>HelloworldRunner</code>，經過一段時間，測試結果如下：

       可以看到分數是30億次，但是這30億指的是什麼呢？仔細觀察 Mode 一項中類型是<code>thrpt</code>，其實就是<code>Throughput</code>吞吐量，代表着每秒完成的次數。

       前面提到測試的類型是吞吐量，也就是一秒鐘調用完成的次數，但是如果想知道做一次需要多少時間該怎麼辦？

其實 1 / 吞吐量 就是這個值

       JMH 提供了以下幾種類型進行支援：

類型

描述

Throughput

每段時間執行的次數，一般是秒

AverageTime

平均時間，每次操作的平均耗時

SampleTime

在測試中，随機進行采樣執行的時間

SingleShotTime

在每次執行中計算耗時

All

顧名思義，所有模式，這個在内部測試中常用

       使用這些模式也非常簡單，隻需要增加<code>@BenchmarkMode</code>注解即可，例如：

       JMH 支援通過<code>@Fork</code>注解完成配置，例如：

       以上注解指<code>init()</code>方法測試時，預熱2輪，正式計量1輪，但是如果測試方法比較多，還是建議通過<code>Options</code>進行配置，具體可以參考<code>HelloworldRunner</code>。

       <code>for</code>循環大家平時經常使用，但是看到過一個優化政策，就是倒序周遊，比如：<code>for (int i = length; i &gt; 0; i--)</code>優于<code>for (int i = 0; i &lt; length; i++)</code>，有些不解。咨詢了溫少，溫少給出的答案是<code>i &gt; 0</code>優于<code>i &lt; length</code>，是以倒序有優勢，那麼我們将這個場景做一下基準測試。

       首先是正向循環，次數是1百萬次疊代。

       接着是逆向循環，次數也是1百萬次。

       最後是一個測試的入口，我們采用3組，每組預熱10輪，正式計量10輪，測試類型是吞吐量。

測試結果如下，有資料表現可以看到逆序在宏觀上是優于正序的。

       HSF預設使用Hessian2進行序列化傳輸，而Hessian2在傳輸時，每次會捎帶上類型元資訊，這些在實際場景下對資源會産生一定的開銷。HSF2.2會使用優化的Hessian2進行序列化，與Hessian2的不同在于，它會基于長連接配接級别緩存元資訊，每次隻會發送資料内容，由于隻發送資料内容，是以資源開銷會更少，我們對Hessian2和優化後的Hssian2做了基準測試，結果如下：

       優化後的hessian在序列化吞吐量上領先hessian2，達到每秒17W，反序列化出乎意料，超過hessian2兩倍，達到32W每秒。

<a href="http://www.baeldung.com/java-microbenchmark-harness">Microbenchmarking with Java</a>

<a href="http://hg.openjdk.java.net/code-tools/jmh/file/fbe1b55eadf8/jmh-samples/src/main/java/org/openjdk/jmh/samples">JMH Samples</a>