摘要: # 使用JMH做Java微基準測試 在使用Java編程過程中,我們對於一些代碼調用的細節有多種編寫方式,但是不確定它們性能時,往往採用重複多次計數的方式來解決。但是隨着JVM不斷的進化,隨着代碼執行次數的增加,JVM會不斷的進行編譯優化,使得重複多少次才能夠得到一個穩定的測試結果變得讓人疑惑,這時候有經驗的同
使用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 {
@Benchmark
public 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.239
CI (99.9%): [3057600556.875, 3111794410.166](assumes normal distribution)
# Run complete. Total time: 00:01:02
Benchmark 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.191
CI (99.9%): [2942730446.601, 3092142601.387](assumes normal distribution)
# Run complete. Total time: 00:02:05
Benchmark 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每秒。