什么是 JMH
JMH 是 Java Microbenchmark Harness 的缩写。中文意思大致是 “JAVA 微基准测试套件”。首先先明白什么是“基准测试”。百度百科给的定义如下：
基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。
可以简单的类比成我们电脑常用的鲁大师，或者手机常用的跑分软件安兔兔之类的性能检测软件。都是按一定的基准或者在特定条件下去测试某一对象的的性能，比如显卡、IO、CPU之类的。
为什么要使用 JMH
基准测试的特质有如下几种：
①、可重复性：可进行重复性的测试，这样做有利于比较每次的测试结果，得到性能结果的长期变化趋势，为系统调优和上线前的容量规划做参考。
②、可观测性：通过全方位的监控（包括测试开始到结束，执行机、服务器、数据库），及时了解和分析测试过程发生了什么。
③、可展示性：相关人员可以直观明了的了解测试结果（web界面、仪表盘、折线图树状图等形式）。
④、真实性：测试的结果反映了客户体验到的真实的情况（真实准确的业务场景+与生产一致的配置+合理正确的测试方法）。
⑤、可执行性：相关人员可以快速的进行测试验证修改调优（可定位可分析）。
可见要做一次符合特质的基准测试，是很繁琐也很困难的。外界因素很容易影响到最终的测试结果。特别对于 JAVA的基准测试。
有些文章会告诉我们 JAVA是 C++编写的，一般来说 JAVA编写的程序不太可能比 C++编写的代码运行效率更好。但是JAVA在某些场景的确要比 C++运行的更高效。不要觉得天方夜谭。其实 JVM随着这些年的发展已经变得很智能，它会在运行期间不断的去优化。
这对于我们程序来说是好事，但是对于性能测试就头疼的。你运行的次数与时间不同可能获得的结果也不同，很难获得一个比较稳定的结果。对于这种情况，有一个解决办法就是大量的重复调用，并且在真正测试前还要进行一定的预热，使结果尽可能的准确。
除了这些，对于结果我们还需要一个很好的展示，可以让我们通过这些展示结果判断性能的好坏。
在使用Java编程过程中，我们对于一些代码调用的细节有多种编写方式，但是不确定它们性能时，往往采用重复多次计数的方式来解决。但是随着JVM不断的进化，随着代码执行次数的增加，JVM会不断的进行编译优化，使得重复多少次才能够得到一个稳定的测试结果变得让人疑惑，这时候有经验的同学就会在测试执行前先循环上万次并注释为预热。
没错！这样做确实可以获得一个偏向正确的测试结果，但是我们试想如果每到需要斟酌性能的时候，都要根据场景写一段预热的逻辑吗？当预热完成后，需要多少次迭代来进行正式内容的测量呢？每次测试结果的输出报告是不是都需要用System.out来输出呢？
其实这些工作都可以交给 JMH (the Java Microbenchmark Harness) ，它被作为Java9的一部分来发布，但是我们完全不需要等待Java9，而可以方便的使用它来简化我们测试，它能够照看好JVM的预热、代码优化，让你的测试过程变得更加简单。
基本概念
Mode
Mode 表示 JMH 进行 Benchmark 时所使用的模式。通常是测量的维度不同，或是测量的方式不同。目前 JMH 共有四种模式：
- Throughput: 整体吞吐量，例如“1秒内可以执行多少次调用”。
- AverageTime: 调用的平均时间，例如“每次调用平均耗时xxx毫秒”。
- SampleTime: 随机取样，最后输出取样结果的分布，例如“99%的调用在xxx毫秒以内，99.99%的调用在xxx毫秒以内”
- SingleShotTime: 以上模式都是默认一次 iteration 是 1s，唯有 SingleShotTime 是只运行一次。往往同时把 warmup 次数设为0，用于测试冷启动时的性能。
Iteration
Iteration 是 JMH 进行测试的最小单位。在大部分模式下，一次 iteration 代表的是一秒，JMH 会在这一秒内不断调用需要 benchmark 的方法，然后根据模式对其采样，计算吞吐量，计算平均执行时间等。
Warmup
Warmup 是指在实际进行 benchmark 前先进行预热的行为。为什么需要预热？因为 JVM 的 JIT 机制的存在，如果某个函数被调用多次之后，JVM 会尝试将其编译成为机器码从而提高执行速度。为了让 benchmark 的结果更加接近真实情况就需要进行预热。
注解与选项
@BenchmarkMode
对应Mode选项，可用于类或者方法上， 需要注意的是，这个注解的value是一个数组，可以把几种Mode集合在一起执行，还可以设置为Mode.All，即全部执行一遍。
@State
类注解，JMH测试类必须使用@State注解，State定义了一个类实例的生命周期，可以类比Spring Bean的Scope。由于JMH允许多线程同时执行测试，不同的选项含义如下：
- Scope.Thread：默认的State，每个测试线程分配一个实例；
- Scope.Benchmark：所有测试线程共享一个实例，用于测试有状态实例在多线程共享下的性能；
- Scope.Group：每个线程组共享一个实例；
@OutputTimeUnit
benchmark 结果所使用的时间单位，可用于类或者方法注解，使用java.util.concurrent.TimeUnit中的标准时间单位。
@Benchmark
方法注解，表示该方法是需要进行 benchmark 的对象。
@Setup
方法注解，会在执行 benchmark 之前被执行，正如其名，主要用于初始化。
@TearDown
方法注解，与@Setup 相对的，会在所有 benchmark 执行结束以后执行，主要用于资源的回收等。
@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":
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。
数据准备
开始测试前，往往有数据准备的需求，比如：初始化一个变量或者一批数据，可以通过构造函数进行初始化，不过 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 全面的考虑的性能测试中环境的影响，所以测试更加的客观。
例子：循环的微基准测试
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测试结果表明：
runCalendar方法平均运行时间为：619微秒
runJoda方法的平均运行时间为：34微秒
据用例测试结果可以看到，Calendar（非线程安全）在高并发情况下性能远远比不上dateTime（线程安全）。对代码性能和安全性要求比较高的可以放弃使用Calendar和SimpleDateFormat（底层实现是Calendar），转而使用joda-time
参考：https://www.jianshu.com/p/bcb0b60c7ca7