正文開始
JMH，即Java Microbenchmark Harness，這是專門用於進行代碼的微基準測試的一套工具API。
JMH 由 OpenJDK/Oracle 裏面那羣開發了 Java 編譯器的大牛們所開發 。何謂 Micro Benchmark 呢？ 簡單地說就是在 method 層面上的 benchmark，精度可以精確到微秒級。
Java的基準測試需要注意的幾個點：
-
測試前需要預熱。
-
防止無用代碼進入測試方法中。
-
併發測試。
-
測試結果呈現。
比較典型的使用場景：
-
當你已經找出了熱點函數，而需要對熱點函數進行進一步的優化時，就可以使用 JMH 對優化的效果進行定量的分析。
-
想定量地知道某個函數需要執行多長時間，以及執行時間和輸入 n 的相關性
-
一個函數有兩種不同實現（例如JSON序列化/反序列化有Jackson和Gson實現），不知道哪種實現性能更好
儘管 JMH 是一個相當不錯的 Micro Benchmark Framework，但很無奈的是網上能夠找到的文檔比較少，而官方也沒有提供比較詳細的文檔，對使用造成了一定的障礙。 但是有個好消息是官方的 Code Sample 寫得非常淺顯易懂， 推薦在需要詳細瞭解 JMH 的用法時可以通讀一遍——本文則會介紹 JMH 最典型的用法和部分常用選項。
第一個例子
添加maven依賴
如果使用maven項目，只需要添加如下依賴：
編寫性能測試
執行方式
這個代碼裏面有好多註解，你第一次見可能不知道什麼意思。先不用管，我待會一一介紹。
我們來運行這個測試，運行JMH基準測試有多種方式，一個是生成jar文件執行， 一個是直接寫main函數或寫單元測試執行。
一般對於大型的測試，需要測試時間比較久，線程比較多的話，就需要去寫好了丟到linux程序裏執行， 不然本機執行很久時間什麼都幹不了了。
先編譯打包之後，然後執行就可以了。當然在執行的時候可以輸入-h參數來看幫助。
另外如果對於一些小的測試，比如我寫的上面這個小例子，在IDE裏面就可以完成了，丟到linux上去太麻煩。 這時候可以在裏面添加一個main函數如下：
這裏其實也比較簡單，new個Options，然後傳入要運行哪個測試，選擇基準測試報告輸出文件地址，然後通過Runner的run方法就可以跑起來了。
報告結果
我們跑一下這個基準測試，完成後打開 E:/Benchmark.log，結果如下：
仔細看，三大部分，第一部分是字符串用加號連接執行的結果，第二部分是StringBuilder執行的結果，第三部分就是兩個的簡單結果比較。這裏注意我們forks傳的2，所以每個測試有兩個fork結果。
前兩部分是一樣的，簡單說下。首先會寫出每部分的一些參數設置，然後是預熱迭代執行（Warmup Iteration）， 然後是正常的迭代執行（Iteration），最後是結果（Result）。這些看看就好，我們最關注的就是第三部分， 其實也就是最終的結論。千萬別看歪了，他輸出的也確實很不爽，error那列其實沒有內容，score的結果是xxx ± xxx，單位是每毫秒多少個操作。可以看到，StringBuilder的速度還確實是要比String進行文字疊加的效率好太多。
註解介紹
好了，當你對JMH有了一個基本認識後，現在來詳細解釋一下前面代碼中的各個註解含義。
@BenchmarkMode
基準測試類型。這裏選擇的是Throughput也就是吞吐量。根據源碼點進去，每種類型後面都有對應的解釋，比較好理解，吞吐量會得到單位時間內可以進行的操作數。
-
Throughput: 整體吞吐量，例如“1秒內可以執行多少次調用”。
-
AverageTime: 調用的平均時間，例如“每次調用平均耗時xxx毫秒”。
-
SampleTime: 隨機取樣，最後輸出取樣結果的分佈，例如“99%的調用在xxx毫秒以內，99.99%的調用在xxx毫秒以內”
-
SingleShotTime: 以上模式都是默認一次 iteration 是 1s，唯有 SingleShotTime 是隻運行一次。往往同時把 warmup 次數設爲0，用於測試冷啓動時的性能。
-
All(“all”, “All benchmark modes”);
@Warmup
上面我們提到了，進行基準測試前需要進行預熱。一般我們前幾次進行程序測試的時候都會比較慢， 所以要讓程序進行幾輪預熱，保證測試的準確性。其中的參數iterations也就非常好理解了，就是預熱輪數。
爲什麼需要預熱？因爲 JVM 的 JIT 機制的存在，如果某個函數被調用多次之後，JVM 會嘗試將其編譯成爲機器碼從而提高執行速度。所以爲了讓 benchmark 的結果更加接近真實情況就需要進行預熱。
@Measurement
度量，其實就是一些基本的測試參數。
-
iterations 進行測試的輪次
-
time 每輪進行的時長
-
timeUnit 時長單位
都是一些基本的參數，可以根據具體情況調整。一般比較重的東西可以進行大量的測試，放到服務器上運行。
@Threads
每個進程中的測試線程，這個非常好理解，根據具體情況選擇，一般爲cpu乘以2。
@Fork
進行 fork 的次數。如果 fork 數是2的話，則 JMH 會 fork 出兩個進程來進行測試。
@OutputTimeUnit
這個比較簡單了，基準測試結果的時間類型。一般選擇秒、毫秒、微秒。
@Benchmark
方法級註解，表示該方法是需要進行 benchmark 的對象，用法和 JUnit 的 @Test 類似。
@Param
屬性級註解，@Param 可以用來指定某項參數的多種情況。特別適合用來測試一個函數在不同的參數輸入的情況下的性能。
@Setup
方法級註解，這個註解的作用就是我們需要在測試之前進行一些準備工作，比如對一些數據的初始化之類的。
@TearDown
方法級註解，這個註解的作用就是我們需要在測試之後進行一些結束工作，比如關閉線程池，數據庫連接等的，主要用於資源的回收等。
@State
當使用@Setup參數的時候，必須在類上加這個參數，不然會提示無法運行。
State 用於聲明某個類是一個“狀態”，然後接受一個 Scope 參數用來表示該狀態的共享範圍。 因爲很多 benchmark 會需要一些表示狀態的類，JMH 允許你把這些類以依賴注入的方式注入到 benchmark 函數裏。Scope 主要分爲三種。
-
Thread: 該狀態爲每個線程獨享。
-
Group: 該狀態爲同一個組裏面所有線程共享。
-
Benchmark: 該狀態在所有線程間共享。
關於State的用法，官方的 code sample 裏有比較好的例子。
第二個例子
再來看一個更常規一點性能測試的例子，
計算 1 ~ n 之和，比較串行算法和並行算法的效率，看 n 在大約多少時並行算法開始超越串行算法
首先定義一個表示這兩種實現的接口：
具體的兩種實現代碼我就不貼了，主要說明一下串行算法和並行算法實現原理：
-
串行算法：使用 for-loop 來計算 n 個正整數之和。
-
並行算法：將所需要計算的 n 個正整數分成 m 份，交給 m 個線程分別計算出和以後，再把它們的結果相加。
進行 benchmark 的代碼如下：
我在自己的筆記本電腦上跑下來的結果，總數在10000時並行算法不如串行算法， 總數達到100000時並行算法開始和串行算法接近，總數達到1000000時並行算法所耗時間約是串行算法的一半左右。
