使用JMH做Java微基准测试

在使用Java编程过程中，我们对于一些代码调用的细节有多种编写方式，但是不确定它们性能时，往往采用重复多次计数的方式来解决。但是随着JVM不断的进化，随着代码执行次数的增加，JVM会不断的进行编译优化，使得重复多少次才能够得到一个稳定的测试结果变得让人疑惑，这时候有经验的同学就会在测试执行前先循环上万次并注释为预热。

没错！这样做确实可以获得一个偏向正确的测试结果，但是我们试想如果每到需要斟酌性能的时候，都要根据场景写一段预热的逻辑吗？当预热完成后，需要多少次迭代来进行正式内容的测量呢？每次测试结果的输出报告是不是都需要用System.out来输出呢？

其实这些工作都可以交给 JMH (the Java Microbenchmark Harness) ，它被作为Java9的一部分来发布，但是我们完全不需要等待Java9，而可以方便的使用它来简化我们测试，它能够照看好JVM的预热、代码优化，让你的测试过程变得更加简单。

三、JMH基本参数概念

3.1　Mode 表示 JMH 进行 Benchmark 时所使用的模式

　　Mode 表示 JMH 进行 Benchmark 时所使用的模式。通常是测量的维度不同，或是测量的方式不同。目前 JMH 共有四种模式：

- Throughput: 整体吞吐量，例如“1秒内可以执行多少次调用”。
- AverageTime: 调用的平均时间，例如“每次调用平均耗时xxx毫秒”。
- SampleTime: 随机取样，最后输出取样结果的分布，例如“99%的调用在xxx毫秒以内，99.99%的调用在xxx毫秒以内”
- SingleShotTime: 以上模式都是默认一次 iteration 是 1s，唯有 SingleShotTime 是只运行一次。往往同时把 warmup 次数设为0，用于测试冷启动时的性能。

3.2　Iteration JMH 进行测试的最小单位

　　Iteration 是 JMH 进行测试的最小单位。在大部分模式下，一次 iteration 代表的是一秒，JMH 会在这一秒内不断调用需要 benchmark 的方法，然后根据模式对其采样，计算吞吐量，计算平均执行时间等。

3.3　Warmup 实际进行 benchmark 前先进行预热的行为

　　Warmup 是指在实际进行 benchmark 前先进行预热的行为。为什么需要预热？因为 JVM 的 JIT 机制的存在，如果某个函数被调用多次之后，JVM 会尝试将其编译成为机器码从而提高执行速度。为了让 benchmark 的结果更加接近真实情况就需要进行预热。

示例：

@BenchmarkMode({Mode.Throughput, Mode.AverageTime}) // 测试方法平均执行时间 @OutputTimeUnit(TimeUnit.SECONDS) // 输出结果的时间粒度为微秒 @State(Scope.Thread) // 每个测试线程一个实例 public class SimpleBenchmark { @Benchmark public void bench() { add(1, 1); } private static int add(int a, int b) { return a + b; } @Benchmark public String stringConcat() { String a = "a"; String b = "b"; String c = "c"; return a + b + c; } public static void main(String[] args) throws RunnerException { Options options = new OptionsBuilder() .include(SimpleBenchmark.class.getSimpleName()) //代表我要测试的是哪个类的方法 .exclude("stringConcat") //代表测试的时候需要排除stringConcat方法 .forks(2) //指的是做2轮测试，在一轮测试无法得出最满意的结果时,可以多测几轮以便得出更全面的测试结果，而每一轮都是先预热，再正式计量。 .warmupIterations(5) //代表先预热5次 .measurementIterations(5) //正式运行测试5次 .build(); new Runner(options).run(); } }

四、注解与选项

4.1 @BenchmarkMode

　　　　对应Mode选项，可用于类或者方法上，需要注意的是，这个注解的value是一个数组，可以把几种Mode集合在一起执行，还可以设置为Mode.All，即全部执行一遍。

4.2　@State

　　　　类注解，JMH测试类必须使用@State注解，State定义了一个类实例的生命周期，可以类比Spring Bean的Scope。由于JMH允许多线程同时执行测试，不同的选项含义如下：

- Scope.Thread：默认的State，每个测试线程分配一个实例；
- Scope.Benchmark：所有测试线程共享一个实例，用于测试有状态实例在多线程共享下的性能；
- Scope.Group：每个线程组共享一个实例；

4.3　@OutputTimeUnit

　　　　benchmark 结果所使用的时间单位，可用于类或者方法注解，使用java.util.concurrent.TimeUnit中的标准时间单位。

4.4　@Benchmark

　　　　方法注解，表示该方法是需要进行 benchmark 的对象。

4.5　@Setup

　　　　方法注解，会在执行 benchmark 之前被执行，正如其名，主要用于初始化。

4.6　@TearDown

　　　　方法注解，与@Setup 相对的，会在所有 benchmark 执行结束以后执行，主要用于资源的回收等。

4.7　@Param

　　　　成员注解，可以用来指定某项参数的多种情况。特别适合用来测试一个函数在不同的参数输入的情况下的性能。@Param注解接收一个String数组，在@setup方法执行前转化为为对应的数据类型。多个@Param注解的成员之间是乘积关系，譬如有两个用@Param注解的字段，第一个有5个值，第二个字段有2个值，那么每个测试方法会跑5*2=10次。

五、示例

首先在项目中新增依赖，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": .521 ±(99.9%) .646 ops/s [Average] (min, avg, max) = (.601, .521, .904), stdev = .239 CI (99.9%): [.875, .166] (assumes normal distribution) # Run complete. Total time: 00:01:02 Benchmark Mode Cnt Score Error Units Helloworld.m thrpt 30 .521 ± .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。

数据准备

开始测试前，往往有数据准备的需求，比如：初始化一个变量或者一批数据，可以通过构造函数进行初始化，不过 JMH 提供了一些手段帮助我们完成这个工作。

@State(Scope.Benchmark) public class Helloworld { private long i; @Setup public void init() { i = System.currentTimeMillis(); } }

上面的例子中，初始化了成员变量i，JMH 会保证在构造Helloworld后调用init()方法。@State(Scope.Benchmark)是修饰成员变量作用域是整个测试，能够被整个测试过程可见。

实现策略

JMH 是通过什么手段来完成测试的呢？预热我们可以通过循环去做，大概1-2万次左右的调用已经足够让代码优化，测试过程我们就通过System.currentTimeMillis()看一下耗时不就行了？

这个问题先放一下，我们看一下 JMH 是如何驱动你的测试的。当我们运行 JMH 基准测试时，它会生成一些Java代码，通常会通过继承你的测试来完成，比如你的测试类型是A，测试方法m()，它会自动生成A_jmhType_B1、A_jmhType_B2、A_jmhType_B3和A_jmhType以及最终的测试执行逻辑A_m_jmhTest。生成代码的一般在classes目录下，看一下生成的类型信息：

public class Helloworld_jmhType_B1 extends com.alibaba.microbenchmark.test.Helloworld { boolean p000, p001, p002, p003, p004, p005, p006, p007, p008, p009, p010, p011, p012, p013, p014, p015; boolean p240, p241, p242, p243, p244, p245, p246, p247, p248, p249, p250, p251, p252, p253, p254, p255; }

可以看到类型中定义了256个boolean，这理论是在做cache line padding，可以猜测 JMH 是想避免CPU缓存对测试过程带来的影响。

public BenchmarkTaskResult m_Throughput(InfraControl control, ThreadParams threadParams) throws Throwable { Helloworld_jmhType l_helloworld0_G = _jmh_tryInit_f_helloworld0_G(control); control.preSetup(); control.announceWarmupReady(); while (control.warmupShouldWait) { l_helloworld0_G.m(); res.allOps++; } m_thrpt_jmhStub(control, res, benchmarkParams, iterationParams, threadParams, blackhole, notifyControl, startRndMask, l_helloworld0_G); }

在最终的测试逻辑代码Helloworld_m_jmhTest中对吞吐量的测试，首先获取了针对Helloworld生成的子类，然后调用Setup，接下来预热，最后进行正式计量。

通过介绍 JMH 的测试过程，就可以回答之前的问题，因为 JMH 全面的考虑的性能测试中环境的影响，所以测试更加的客观。

示例1：循环的微基准测试

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 < ; i++) { } } }

接着是逆向循环，次数也是1百万次。

public class CountPerf { @Benchmark @BenchmarkMode(Mode.Throughput) public void count() { for (int i = ; 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": .994 ±(99.9%) .393 ops/s [Average] (min, avg, max) = (.002, .994, .013), stdev = .191 CI (99.9%): [.601, .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 .097 ± .885 ops/s c.a.m.forward.CountPerf.count thrpt 30 .994 ± .393 ops/s

示例2：Calendar和dateTime对比的基准测试

JMH性能测试 – 漂泊之枫 – 博客园

　测试结果表明：

　　　　runCalendar方法平均运行时间为：619微秒

　　　　runJoda方法的平均运行时间为：34微秒

　　据用例测试结果可以看到，Calendar（非线程安全）在高并发情况下性能远远比不上dateTime（线程安全）。对代码性能和安全性要求比较高的可以放弃使用Calendar和SimpleDateFormat（底层实现是Calendar），转而使用joda-time

示例3：几种字符串拼接方法的基准测试

package com.dxz.statement; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.RunnerException; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; public class StringConnectBenchmark { / * 字符串拼接之 StringBuilder 基准测试 */ @Benchmark public void testStringBuilder() { print(new StringBuilder().append(1).append(2).append(3).toString()); } / * 字符串拼接之直接相加基准测试 */ @Benchmark public void testStringAdd() { print(new String()+ 1 + 2 + 3); } / * 字符串拼接之String Concat基准测试 */ @Benchmark public void testStringConcat() { print(new String().concat("1").concat("2").concat("3")); } / * 字符串拼接之 StringBuffer 基准测试 */ @Benchmark public void testStringBuffer() { print(new StringBuffer().append(1).append(2).append(3).toString()); } / * 字符串拼接之 StringFormat 基准测试 */ @Benchmark public void testStringFormat(){ print(String.format("%s%s%s", 1, 2, 3)); } public void print(String str) { } public static void main( String[] args ) throws RunnerException { Options opt = new OptionsBuilder() // 导入要测试的类 .include(StringConnectBenchmark.class.getSimpleName()) // 预热5轮 .warmupIterations(5) // 度量10轮 .measurementIterations(10) .mode(Mode.Throughput) .forks(3) .build(); new Runner(opt).run(); } }

结果：

C:\java\jdk1.8.0_111\bin\java.exe -Dfile.encoding=UTF-8 -classpath D:\study\jmh\benchmark-demo\target\classes;C:\Users\4cv748wpd3\.m2\repository\org\openjdk\jmh\jmh-core\1.25\jmh-core-1.25.jar;C:\Users\4cv748wpd3\.m2\repository\net\sf\jopt-simple\jopt-simple\4.6\jopt-simple-4.6.jar;C:\Users\4cv748wpd3\.m2\repository\org\apache\commons\commons-math3\3.2\commons-math3-3.2.jar;C:\Users\4cv748wpd3\.m2\repository\junit\junit\4.11\junit-4.11.jar;C:\Users\4cv748wpd3\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar org.openjdk.jmh.Main com.dxz.statement.StringConnectBenchmark.* # JMH version: 1.25 # VM version: JDK 1.8.0_111, Java HotSpot(TM) 64-Bit Server VM, 25.111-b14 # VM invoker: C:\java\jdk1.8.0_111\jre\bin\java.exe # VM options: -Dfile.encoding=UTF-8 # 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: com.dxz.statement.StringConnectBenchmark.testStringAdd # Run progress: 0.00% complete, ETA 00:41:40 # Fork: 1 of 5 # Warmup Iteration 1: .234 ops/s # Warmup Iteration 2: .486 ops/s # Warmup Iteration 3: .317 ops/s # Warmup Iteration 4: .747 ops/s # Warmup Iteration 5: .979 ops/s Iteration 1: .253 ops/s Iteration 2: .004 ops/s Iteration 3: .000 ops/s Iteration 4: .638 ops/s Iteration 5: .541 ops/s # Run progress: 4.00% complete, ETA 00:40:31 # Fork: 2 of 5 # Warmup Iteration 1: .015 ops/s # Warmup Iteration 2: .740 ops/s # Warmup Iteration 3: .337 ops/s # Warmup Iteration 4: .706 ops/s # Warmup Iteration 5: .260 ops/s Iteration 1: .618 ops/s Iteration 2: .319 ops/s Iteration 3: .960 ops/s Iteration 4: .377 ops/s Iteration 5: .925 ops/s # Run progress: 8.00% complete, ETA 00:38:44 # Fork: 3 of 5 # Warmup Iteration 1: .011 ops/s # Warmup Iteration 2: .287 ops/s # Warmup Iteration 3: .399 ops/s # Warmup Iteration 4: .124 ops/s # Warmup Iteration 5: .501 ops/s Iteration 1: .357 ops/s Iteration 2: .198 ops/s Iteration 3: .902 ops/s Iteration 4: .515 ops/s Iteration 5: .038 ops/s # Run progress: 12.00% complete, ETA 00:37:02 # Fork: 4 of 5 # Warmup Iteration 1: .562 ops/s # Warmup Iteration 2: .563 ops/s # Warmup Iteration 3: .977 ops/s # Warmup Iteration 4: .906 ops/s # Warmup Iteration 5: .853 ops/s Iteration 1: .525 ops/s Iteration 2: .011 ops/s Iteration 3: .586 ops/s Iteration 4: .153 ops/s Iteration 5: .964 ops/s # Run progress: 16.00% complete, ETA 00:35:20 # Fork: 5 of 5 # Warmup Iteration 1: .386 ops/s # Warmup Iteration 2: .845 ops/s # Warmup Iteration 3: .303 ops/s # Warmup Iteration 4: .144 ops/s # Warmup Iteration 5: .324 ops/s Iteration 1: .023 ops/s Iteration 2: .112 ops/s Iteration 3: .355 ops/s Iteration 4: .548 ops/s Iteration 5: .990 ops/s Result "com.dxz.statement.StringConnectBenchmark.testStringAdd": .796 ±(99.9%) .257 ops/s [Average] (min, avg, max) = (.960, .796, .964), stdev = .227 CI (99.9%): [.539, .054] (assumes normal distribution) # JMH version: 1.25 # VM version: JDK 1.8.0_111, Java HotSpot(TM) 64-Bit Server VM, 25.111-b14 # VM invoker: C:\java\jdk1.8.0_111\jre\bin\java.exe # VM options: -Dfile.encoding=UTF-8 # 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: com.dxz.statement.StringConnectBenchmark.testStringBuffer # Run progress: 20.00% complete, ETA 00:33:38 # Fork: 1 of 5 # Warmup Iteration 1: .063 ops/s # Warmup Iteration 2: .373 ops/s # Warmup Iteration 3: .750 ops/s # Warmup Iteration 4: .782 ops/s # Warmup Iteration 5: .834 ops/s Iteration 1: .718 ops/s Iteration 2: .881 ops/s Iteration 3: .447 ops/s Iteration 4: .520 ops/s Iteration 5: .418 ops/s # Run progress: 24.00% complete, ETA 00:31:57 # Fork: 2 of 5 # Warmup Iteration 1: .693 ops/s # Warmup Iteration 2: .600 ops/s # Warmup Iteration 3: .822 ops/s # Warmup Iteration 4: .116 ops/s # Warmup Iteration 5: .817 ops/s Iteration 1: .781 ops/s Iteration 2: .687 ops/s Iteration 3: .990 ops/s Iteration 4: .320 ops/s Iteration 5: .755 ops/s # Run progress: 28.00% complete, ETA 00:30:16 # Fork: 3 of 5 # Warmup Iteration 1: .282 ops/s # Warmup Iteration 2: .229 ops/s # Warmup Iteration 3: .598 ops/s # Warmup Iteration 4: .752 ops/s # Warmup Iteration 5: .600 ops/s Iteration 1: .029 ops/s Iteration 2: .610 ops/s Iteration 3: .188 ops/s Iteration 4: .167 ops/s Iteration 5: .617 ops/s # Run progress: 32.00% complete, ETA 00:28:35 # Fork: 4 of 5 # Warmup Iteration 1: .724 ops/s # Warmup Iteration 2: .923 ops/s # Warmup Iteration 3: .734 ops/s # Warmup Iteration 4: .725 ops/s # Warmup Iteration 5: .219 ops/s Iteration 1: .351 ops/s Iteration 2: .911 ops/s Iteration 3: .935 ops/s Iteration 4: .060 ops/s Iteration 5: .147 ops/s # Run progress: 36.00% complete, ETA 00:26:54 # Fork: 5 of 5 # Warmup Iteration 1: .246 ops/s # Warmup Iteration 2: .625 ops/s # Warmup Iteration 3: .920 ops/s # Warmup Iteration 4: .663 ops/s # Warmup Iteration 5: .784 ops/s Iteration 1: .956 ops/s Iteration 2: .842 ops/s Iteration 3: .053 ops/s Iteration 4: .726 ops/s Iteration 5: .483 ops/s Result "com.dxz.statement.StringConnectBenchmark.testStringBuffer": .744 ±(99.9%) .127 ops/s [Average] (min, avg, max) = (.718, .744, .726), stdev = .378 CI (99.9%): [.617, .870] (assumes normal distribution) # JMH version: 1.25 # VM version: JDK 1.8.0_111, Java HotSpot(TM) 64-Bit Server VM, 25.111-b14 # VM invoker: C:\java\jdk1.8.0_111\jre\bin\java.exe # VM options: -Dfile.encoding=UTF-8 # 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: com.dxz.statement.StringConnectBenchmark.testStringBuilder # Run progress: 40.00% complete, ETA 00:25:13 # Fork: 1 of 5 # Warmup Iteration 1: .117 ops/s # Warmup Iteration 2: .130 ops/s # Warmup Iteration 3: .615 ops/s # Warmup Iteration 4: .296 ops/s # Warmup Iteration 5: .685 ops/s Iteration 1: .275 ops/s Iteration 2: .277 ops/s Iteration 3: .937 ops/s Iteration 4: .388 ops/s Iteration 5: .743 ops/s # Run progress: 44.00% complete, ETA 00:23:32 # Fork: 2 of 5 # Warmup Iteration 1: .169 ops/s # Warmup Iteration 2: .627 ops/s # Warmup Iteration 3: .612 ops/s # Warmup Iteration 4: .859 ops/s # Warmup Iteration 5: .752 ops/s Iteration 1: .941 ops/s Iteration 2: .755 ops/s Iteration 3: .044 ops/s Iteration 4: .847 ops/s Iteration 5: .336 ops/s # Run progress: 48.00% complete, ETA 00:21:51 # Fork: 3 of 5 # Warmup Iteration 1: .256 ops/s # Warmup Iteration 2: .486 ops/s # Warmup Iteration 3: .232 ops/s # Warmup Iteration 4: .672 ops/s # Warmup Iteration 5: .403 ops/s Iteration 1: .703 ops/s Iteration 2: .483 ops/s Iteration 3: .907 ops/s Iteration 4: .535 ops/s Iteration 5: .202 ops/s # Run progress: 52.00% complete, ETA 00:20:10 # Fork: 4 of 5 # Warmup Iteration 1: .868 ops/s # Warmup Iteration 2: .139 ops/s # Warmup Iteration 3: .718 ops/s # Warmup Iteration 4: .205 ops/s # Warmup Iteration 5: .960 ops/s Iteration 1: .221 ops/s Iteration 2: .276 ops/s Iteration 3: .975 ops/s Iteration 4: .135 ops/s Iteration 5: .507 ops/s # Run progress: 56.00% complete, ETA 00:18:29 # Fork: 5 of 5 # Warmup Iteration 1: .221 ops/s # Warmup Iteration 2: .439 ops/s # Warmup Iteration 3: .731 ops/s # Warmup Iteration 4: .522 ops/s # Warmup Iteration 5: .972 ops/s Iteration 1: .801 ops/s Iteration 2: .101 ops/s Iteration 3: .433 ops/s Iteration 4: .091 ops/s Iteration 5: .843 ops/s Result "com.dxz.statement.StringConnectBenchmark.testStringBuilder": .390 ±(99.9%) .727 ops/s [Average] (min, avg, max) = (.941, .390, .275), stdev = .515 CI (99.9%): [.663, .118] (assumes normal distribution) # JMH version: 1.25 # VM version: JDK 1.8.0_111, Java HotSpot(TM) 64-Bit Server VM, 25.111-b14 # VM invoker: C:\java\jdk1.8.0_111\jre\bin\java.exe # VM options: -Dfile.encoding=UTF-8 # 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: com.dxz.statement.StringConnectBenchmark.testStringConcat # Run progress: 60.00% complete, ETA 00:16:48 # Fork: 1 of 5 # Warmup Iteration 1: .305 ops/s # Warmup Iteration 2: .100 ops/s # Warmup Iteration 3: .371 ops/s # Warmup Iteration 4: .597 ops/s # Warmup Iteration 5: .252 ops/s Iteration 1: .986 ops/s Iteration 2: .837 ops/s Iteration 3: .068 ops/s Iteration 4: .534 ops/s Iteration 5: .102 ops/s # Run progress: 64.00% complete, ETA 00:15:07 # Fork: 2 of 5 # Warmup Iteration 1: .016 ops/s # Warmup Iteration 2: .330 ops/s # Warmup Iteration 3: .724 ops/s # Warmup Iteration 4: .496 ops/s # Warmup Iteration 5: .168 ops/s Iteration 1: .865 ops/s Iteration 2: .542 ops/s Iteration 3: .060 ops/s Iteration 4: .465 ops/s Iteration 5: .418 ops/s # Run progress: 68.00% complete, ETA 00:13:26 # Fork: 3 of 5 # Warmup Iteration 1: .634 ops/s # Warmup Iteration 2: .340 ops/s # Warmup Iteration 3: .396 ops/s # Warmup Iteration 4: .117 ops/s # Warmup Iteration 5: .214 ops/s Iteration 1: .055 ops/s Iteration 2: .925 ops/s Iteration 3: .290 ops/s Iteration 4: .784 ops/s Iteration 5: .868 ops/s # Run progress: 72.00% complete, ETA 00:11:45 # Fork: 4 of 5 # Warmup Iteration 1: .148 ops/s # Warmup Iteration 2: .335 ops/s # Warmup Iteration 3: .155 ops/s # Warmup Iteration 4: .168 ops/s # Warmup Iteration 5: .392 ops/s Iteration 1: .204 ops/s Iteration 2: .757 ops/s Iteration 3: .571 ops/s Iteration 4: .180 ops/s Iteration 5: .433 ops/s # Run progress: 76.00% complete, ETA 00:10:05 # Fork: 5 of 5 # Warmup Iteration 1: .211 ops/s # Warmup Iteration 2: .267 ops/s # Warmup Iteration 3: .910 ops/s # Warmup Iteration 4: .754 ops/s # Warmup Iteration 5: .033 ops/s Iteration 1: .846 ops/s Iteration 2: .552 ops/s Iteration 3: .043 ops/s Iteration 4: .337 ops/s Iteration 5: .433 ops/s Result "com.dxz.statement.StringConnectBenchmark.testStringConcat": .646 ±(99.9%) .955 ops/s [Average] (min, avg, max) = (.986, .646, .865), stdev = .228 CI (99.9%): [.691, .601] (assumes normal distribution) # JMH version: 1.25 # VM version: JDK 1.8.0_111, Java HotSpot(TM) 64-Bit Server VM, 25.111-b14 # VM invoker: C:\java\jdk1.8.0_111\jre\bin\java.exe # VM options: -Dfile.encoding=UTF-8 # 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: com.dxz.statement.StringConnectBenchmark.testStringFormat # Run progress: 80.00% complete, ETA 00:08:24 # Fork: 1 of 5 # Warmup Iteration 1: .849 ops/s # Warmup Iteration 2: .182 ops/s # Warmup Iteration 3: .129 ops/s # Warmup Iteration 4: .936 ops/s # Warmup Iteration 5: .422 ops/s Iteration 1: .196 ops/s Iteration 2: .363 ops/s Iteration 3: .708 ops/s Iteration 4: .920 ops/s Iteration 5: .429 ops/s # Run progress: 84.00% complete, ETA 00:06:43 # Fork: 2 of 5 # Warmup Iteration 1: .002 ops/s # Warmup Iteration 2: .623 ops/s # Warmup Iteration 3: .660 ops/s # Warmup Iteration 4: .973 ops/s # Warmup Iteration 5: .233 ops/s Iteration 1: .774 ops/s Iteration 2: .480 ops/s Iteration 3: .131 ops/s Iteration 4: .849 ops/s Iteration 5: .976 ops/s # Run progress: 88.00% complete, ETA 00:05:02 # Fork: 3 of 5 # Warmup Iteration 1: .163 ops/s # Warmup Iteration 2: .810 ops/s # Warmup Iteration 3: .128 ops/s # Warmup Iteration 4: .206 ops/s # Warmup Iteration 5: .345 ops/s Iteration 1: .168 ops/s Iteration 2: .423 ops/s Iteration 3: .616 ops/s Iteration 4: .116 ops/s Iteration 5: .788 ops/s # Run progress: 92.00% complete, ETA 00:03:21 # Fork: 4 of 5 # Warmup Iteration 1: .486 ops/s # Warmup Iteration 2: .984 ops/s # Warmup Iteration 3: .992 ops/s # Warmup Iteration 4: .213 ops/s # Warmup Iteration 5: .074 ops/s Iteration 1: .780 ops/s Iteration 2: .478 ops/s Iteration 3: .664 ops/s Iteration 4: .231 ops/s Iteration 5: .831 ops/s # Run progress: 96.00% complete, ETA 00:01:40 # Fork: 5 of 5 # Warmup Iteration 1: .552 ops/s # Warmup Iteration 2: .965 ops/s # Warmup Iteration 3: .339 ops/s # Warmup Iteration 4: .666 ops/s # Warmup Iteration 5: .054 ops/s Iteration 1: .461 ops/s Iteration 2: .617 ops/s Iteration 3: .834 ops/s Iteration 4: .432 ops/s Iteration 5: .672 ops/s Result "com.dxz.statement.StringConnectBenchmark.testStringFormat": .677 ±(99.9%) 25605.464 ops/s [Average] (min, avg, max) = (.708, .677, .432), stdev = 34182.562 CI (99.9%): [.213, .142] (assumes normal distribution) # Run complete. Total time: 00:42:00 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. Benchmark Mode Cnt Score Error Units StringConnectBenchmark.testStringAdd thrpt 25 .796 ± .257 ops/s StringConnectBenchmark.testStringBuffer thrpt 25 .744 ± .127 ops/s StringConnectBenchmark.testStringBuilder thrpt 25 .390 ± .727 ops/s StringConnectBenchmark.testStringConcat thrpt 25 .646 ± .955 ops/s StringConnectBenchmark.testStringFormat thrpt 25 .677 ± 25605.464 ops/s Process finished with exit code 0

结果分析：

结论：

StringBuffer >= StringBuilder > String直接相加 > StringConcat >> StringFormat

可见 StringBuffer 与 StringBuilder 大致性能相同，都比直接相加高几个数量级，而且直接相加与 Concat 方法相加差不多。但是这里不管哪种都比 StringFormat高 N 个数量级。所以 String的 Format方法一定要慎用、不用、禁用！！！

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/109760.html

使用JMH做Java微基准测试

一、什么是 JMH

二、为什么要使用 JMH

三、JMH基本参数概念

3.1 Mode 表示 JMH 进行 Benchmark 时所使用的模式

3.2 Iteration JMH 进行测试的最小单位

3.3 Warmup 实际进行 benchmark 前先进行预热的行为