浅谈Java基准性能测试之JMH 浅谈Java基准性能测试之JMH

一、JMH vs JMeter
二、JMH基本用法

2.1、创建JMH项目
2.2、编写基准测试代码
2.3、JMH打包、运行
2.4、JMH与Springboot

三、JMH注解

3.1、JMH Benchmark Modes
3.2、Benchmark Time Units
3.3、Benchmark State
3.4、State Object @Setup @TearDown
3.5、Fork
3.6、Thread
3.7、Warmup
3.8、Measurement

四、输出测试结果

一、JMH vs JMeter JMeter可能是最常用的性能测试工具。它既支持图形界面，也支持命令行，属于黑盒测试的范畴，对非开发人员比较友好，上手也非常容易。图形界面一般用于编写、调试测试用例，而实际的性能测试建议还是在命令行下运行。
很多场景下JMeter和JMH都可以做性能测试，但是对于严格意义上的基准测试来说，只有JMH才适合。JMeter的测试结果精度相对JVM较低、所以JMeter不适合于类级别的基准测试，更适合于对精度要求不高、耗时相对较长的操作。
JMeter测试精度差： JMeter自身框架比较重，举个例子：使用JMH测试一个方法，平均耗时0.01ms，而使用JMeter测试的结果平均耗时20ms，相差200倍。JMeter内置很多采样器：JMeter内置了支持多种网络协议的采样器，可以在不写Java代码的情况下实现很多复杂的测试。JMeter支持集群的方式运行，方便模拟多用户、高并发压力测试。
总结： JMeter适合一些相对耗时的集成功能测试，如API接口的测试。JMH适合于类或者方法的单元测试。

二、JMH基本用法
2.1、创建JMH项目
官方推荐为JMH基准测试创建单独的项目，最简单的创建JMH项目的方法就是基于maven项目原型的方式创建（如果是在windows环境下，需要对org.open.jdk.jmh这样带.的用双引号包裹）。

mvn archetype:generate
-DinteractiveMode=false
-DarchetypeGroupId=org.openjdk.jmh
-DarchetypeArtifactId=jmh-java-benchmark-archetype
-DarchetypeVersion=1.21
-DgroupId=com.jenkov
-DartifactId=first-benchmark
-Dversion=1.0

可以看到生成的项目pom文件中主要是添加了两个jmh
的依赖和设置了maven-shade-plugin的编译方式（负责把项目的所有依赖jar包打入到目标jar包中，与springboot的实现方式类似）。

org.openjdk.jmhjmh-core${jmh.version}org.openjdk.jmhjmh-generator-annprocess${jmh.version}provided...org.apache.maven.pluginsmaven-shade-plugin2.2packageshade${uberjar.name}org.openjdk.jmh.Main*:*META-INF/*.SFMETA-INF/*.DSAMETA-INF/*.RSA

生成的项目中已经包含了一个class文件MyBenchmark.java，如下：

public class MyBenchmark {@Benchmarkpublic void testMethod() {// This is a demo/sample template for building your JMH benchmarks. Edit as needed.// Put your benchmark code here.}}

2.2、编写基准测试代码
在上面生成的MyBenchmark类的testMethod中就可以添加基准测试的java代码，举例如下：测试AtomicInteger的incrementAndGet的基准性能。

public class MyBenchmark {static AtomicInteger integer = new AtomicInteger(); @Benchmarkpublic void testMethod() {// This is a demo/sample template for building your JMH benchmarks. Edit as needed.// Put your benchmark code here.integer.incrementAndGet(); }}

2.3、JMH打包、运行
项目打包

mvn clean install

运行生成的目标jar包benchmark.jar：

java -jar benchmark.jar

# JMH version: 1.21
# VM version: JDK 1.8.0_181, Java HotSpot(TM) 64-Bit Server VM, 25.181-b13
# VM invoker: C:\Java\jdk1.8.0_181\jre\bin\java.exe
# VM options:
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.testMethod

# Run progress: 0.00% complete, ETA 00:01:40
# Fork: 1 of 1
# Warmup Iteration1: 81052462.185 ops/s
# Warmup Iteration2: 80152956.333 ops/s
# Warmup Iteration3: 81305026.522 ops/s
# Warmup Iteration4: 81740215.227 ops/s
# Warmup Iteration5: 82398485.097 ops/s
Iteration1: 82176523.804 ops/s
Iteration2: 81818881.730 ops/s
Iteration3: 82812749.807 ops/s
Iteration4: 82406672.531 ops/s
Iteration5: 74270344.512 ops/s

Result "org.sample.MyBenchmark.testMethod":
80697034.477 ±(99.9%) 13903555.960 ops/s [Average]
(min, avg, max) = (74270344.512, 80697034.477, 82812749.807), stdev = 3610709.330
CI (99.9%): [66793478.517, 94600590.437] (assumes normal distribution)

# Run complete. Total time: 00:01:41

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

BenchmarkModeCntScoreErrorUnits
MyBenchmark.testMethodthrpt580697034.477 ± 13903555.960ops/s

从上面的日志我们大致可以了解到 JMH的基准测试主要经历了下面几个过程：
1.打印本次测试的配置，warmup：5轮；measurement：5轮；每轮：10s；启动1个线程做测试；基准测试指标：吞吐量（throughput，单位是s）；测试方法MyBenchmark.testMethod
2.启动一个JVM进程做基准测试（也可以设置启动多个进程，减少随机因素的误差影响）
3.在JVM进程中先执行了5轮的预热（warmup），每轮10s，总共50s的预热时间。预热的数据不作为基准测试的参考。
4.测试了5轮，每轮10s，总共50s的测试时间
5.汇总测试数据、生成结果报表。最终结论是吞吐量（80697034.477 ±13903555.960 ops/s）,其中80697034.477 是结果，13903555.960是误差范围。

2.4、JMH与Springboot
在对Springboot项目做JMH基准测试时可能会因为maven-shade-plugin插件的问题打包报错，需要在JMH的maven-shade-plugin的插件配置中添加id即可。项目的pom可能如下：

4.0.0org.springframework.bootspring-boot-starter-parent2.0.7.RELEASE...org.apache.maven.pluginsmaven-shade-plugin2.2shade-all-dependency-jarpackageshade......

在测试代码中正常基于SpringBootApplication构建ConfigurableApplicationContext从而获取bean的方式获取对象测试即可。

public class StringRedisTemplateBenchmark{StringRedisTemplate redisTemplate; @Setup(Level.Trial)public void setUp() {redisTemplate = SpringApplication.run(SpringBootApplicationClass.class).getBean(StringRedisTemplate.class); }@Benchmarkpublic void testGet() {redisTemplate.opsForValue().get("testkey"); }}@SpringBootApplicationpublic class SpringBootApplicationClass {}

application.properties

lettuce.pool.maxTotal=50lettuce.pool.maxIdle=10lettuce.pool.minIdle=0lettuce.sentinel.master=mymasterlettuce.sentinel.nodes=10.xx.xx.xx:26379,10.xx.xx.xx:26379lettuce.password=xxxxxx

三、JMH注解 JMH测试的相关配置大多是通过注解的方式体现的。
具体每个注解的使用实例也可以参考官网
http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/

3.1、JMH Benchmark Modes
JMH benchmark支持如下几种测试模式：

Throughput：吞吐量，测试每秒可以执行操作的次数
Average Time：平均耗时，测试单次操作的平均耗时
Sample Time：采样耗时，测试单次操作的耗时，包括最大、最小耗时，已经百分位耗时等
Single Shot Time：只计算一次的耗时，一般用来测试冷启动的性能（不设置JVM预热）
All：测试上面的所有指标

默认的benchmark mode是Throughput，可以通过注解的方式设置BenchmarkMode，注解支持放在类或方法上。如下所示设置了Throughput和SampleTime两个Benchmark mode。

@BenchmarkMode({Mode.Throughput, Mode.SampleTime})public class MyBenchmark {static AtomicInteger integer = new AtomicInteger(); @Benchmarkpublic void testMethod() {// This is a demo/sample template for building your JMH benchmarks. Edit as needed.// Put your benchmark code here.integer.incrementAndGet(); }}

3.2、Benchmark Time Units
JMH支持设置打印基准测试结果的时间单位，通过@OutputTimeUnit注解的方式设置。

@OutputTimeUnit(TimeUnit.SECONDS)public class MyBenchmark {static AtomicInteger integer = new AtomicInteger(); @Benchmarkpublic void testMethod() {integer.incrementAndGet(); }}

3.3、Benchmark State
有时候我们在做基准测试的时候会需要使用一些变量、字段，@State注解是用来配置这些变量的生命周期，@State注解可以放在类上，然后在基准测试方法中可以通过参数的方式把该类对象作为参数使用。@State支持的生命周期类型：

Benchmark：整个基准测试的生命周期，多个线程共用同一份实例对象。该类内部的@Setup @TearDown注解的方法可能会被任一个线程执行，但是只会执行一次。
Group：每一个Group内部共享同一个实例，需要配合@Group @GroupThread使用。该类内部的@Setup @TearDown注解的方法可能会该Group内的任一个线程执行，但是只会执行一次。
Thread：每个线程的实例都是不同的、唯一的。该类内部的@Setup @TearDown注解的方法只会被当前线程执行，而且只会执行一次。

被@State标示的类必须满足如下两个要求：
类必须是public的
必须有无参构造函数

3.4、State Object @Setup @TearDown
在@Scope注解标示的类的方法上可以添加@Setup和@TearDwon注解。@Setup：用来标示在Benchmark方法使用State对象之前需要执行的操作。@TearDown：用来标示在Benchmark方法之后需要对State对象执行的操作。
如下示例：

@OutputTimeUnit(TimeUnit.SECONDS)public class MyBenchmark {@Benchmarkpublic void testMethod(TestAddAndGetState state) {state.getInteger().incrementAndGet(); }@State(Scope.Benchmark)public static class TestAddAndGetState {private AtomicInteger integer; @Setup(Level.Iteration)public void setup() {integer = new AtomicInteger(); }public AtomicInteger getInteger() {return integer; }}}

@Setup、@TearDown支持设置Level级别，Level有三个值：

Trial：每次benchmark前/后执行一次，每次benchmark会包含多轮（Iteration）
Iteration：每轮执行前/后执行一次
Invocation：每次调用测试的方法前/后都执行一次，这个执行频率会很高，一般用不上。

3.5、Fork
@Fork注解用来设置启动的JVM进程数量，多个进程是串行的方式启动的，多个进程可以减少偶发因素对测试结果的影响。

3.6、Thread
@Thread用来配置执行测试启动的线程数量

3.7、Warmup
@Warmup 用来配置预热的时间，如下所示配置预热五轮，每轮1second，也就是说总共会预热5s左右，在这5s内会不停的循环调用测试方法，但是预热时的数据不作为测试结果参考。