摘要： # 使用JMH做Java微基準測試 在使用Java編程過程中，我們對于一些代碼調用的細節有多種編寫方式，但是不確定它們性能時，往往采用重復多次計數的方式來解決。但是隨著JVM不斷的進化，隨著代碼執行次數的增加，JVM會不斷的進行編譯優化，使得重復多少次才能夠得到一個穩定的測試結果變得讓人疑惑，這時候有經驗的同

查看原文鏈接：click.aliyun.com/m/40240/

使用JMH做Java微基準測試

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

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

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

開始

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

<dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-core</artifactId><version>1.19</version> </dependency> <dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-generator-annprocess</artifactId><version>1.19</version> </dependency>復制代碼

創建一個Helloworld類，里面只有一個空方法m()，標注了@Benchmark的注解，聲明這個方法為一個微基準測試方法，JMH 會在編譯期生成基準測試的代碼，并運行它。

public class Helloworld {@Benchmarkpublic void m() {} }復制代碼

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

public class HelloworldRunner {public static void main(String[] args) throws RunnerException {Options opt = new OptionsBuilder().include("Helloworld").exclude("Pref").warmupIterations(10).measurementIterations(10).forks(3).build();new Runner(opt).run();} }復制代碼

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

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

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

我們運行HelloworldRunner，經過一段時間，測試結果如下：

Result "com.alibaba.microbenchmark.test.Helloworld.m":3084697483.521 ±(99.9%) 27096926.646 ops/s [Average](min, avg, max) = (2951123277.601, 3084697483.521, 3121456015.904), stdev = 40557407.239CI (99.9%): [3057600556.875, 3111794410.166](assumes normal distribution)# Run complete. Total time: 00:01:02Benchmark Mode Cnt Score Error Units Helloworld.m thrpt 30 3084697483.521 ± 27096926.646 ops/s復制代碼

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

測試類型

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

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

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

類型描述

Throughput	每段時間執行的次數，一般是秒
AverageTime	平均時間，每次操作的平均耗時
SampleTime	在測試中，隨機進行采樣執行的時間
SingleShotTime	在每次執行中計算耗時
All	顧名思義，所有模式，這個在內部測試中常用

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

@Benchmark @BenchmarkMode({Mode.Throughput, Mode.SingleShotTime}) public void m() {}復制代碼

配置策略

JMH 支持通過@Fork注解完成配置，例如：

@Benchmark @Fork(value = 1, warmups = 2) @BenchmarkMode(Mode.Throughput) public void init() {}復制代碼

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

例子：循環的微基準測試

for循環大家平時經常使用，但是看到過一個優化策略，就是倒序遍歷，比如：for (int i = length; i > 0; i--)優于for (int i = 0; i < length; i++)，有些不解。咨詢了溫少，溫少給出的答案是i > 0優于i < length，因此倒序有優勢，那么我們將這個場景做一下基準測試。

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

public class CountPerf {@Benchmark@BenchmarkMode(Mode.Throughput)public void count() {for (int i = 0; i < 1_000_000; i++) {}} }復制代碼

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

public class CountPerf {@Benchmark@BenchmarkMode(Mode.Throughput)public void count() {for (int i = 1_000_000; i > 0; i--) {}} }復制代碼

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

public class BenchmarkRunner {public static void main(String[] args) throws RunnerException {Options opt = new OptionsBuilder().include("Perf").exclude("Helloworld").warmupIterations(10).measurementIterations(10).forks(3).build();new Runner(opt).run();} }復制代碼

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

Result "com.alibaba.microbenchmark.forward.CountPerf.count":3017436523.994 ±(99.9%) 74706077.393 ops/s [Average](min, avg, max) = (2586477493.002, 3017436523.994, 3090537220.013), stdev = 111816548.191CI (99.9%): [2942730446.601, 3092142601.387](assumes normal distribution)# Run complete. Total time: 00:02:05Benchmark Mode Cnt Score Error Units c.a.m.backward.CountPerf.count thrpt 30 3070589161.097 ± 30858669.885 ops/s c.a.m.forward.CountPerf.count thrpt 30 3017436523.994 ± 74706077.393 ops/s復制代碼

優化的Hessian2微基準測試

HSF默認使用Hessian2進行序列化傳輸，而Hessian2在傳輸時，每次會捎帶上類型元信息，這些在實際場景下對資源會產生一定的開銷。HSF2.2會使用優化的Hessian2進行序列化，與Hessian2的不同在于，它會基于長連接級別緩存元信息，每次只會發送數據內容，由于只發送數據內容，所以資源開銷會更少，我們對Hessian2和優化后的Hssian2做了基準測試，結果如下：

Benchmark Mode Cnt Score Error Units c.a.m.h.hessian.DeserialPerf.deserial thrpt 60 147255.638 ± 1057.106 ops/s c.a.m.h.hessian.SerialPerf.serial thrpt 60 146336.439 ± 1199.087 ops/s c.a.m.h.optihessian.DeserialPerf.deserial thrpt 60 327482.489 ± 3366.174 ops/s c.a.m.h.optihessian.SerialPerf.serial thrpt 60 176988.488 ± 1233.302 ops/s復制代碼

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

參考

• Microbenchmarking with Java
• JMH Samples

總結

以上是生活随笔為你收集整理的使用JMH做Java微基准测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。