凡隐的博客

平凡的世界

0%

JMH(Java Microbenchmark Harness)笔记

发表于 更新于 分类于

看开源项目时，时不常遇到一个叫做benchmark的目录，此时脑子停滞，一眼带过，最近一次看到就顺手问了下谷大哥，发现benchmark还是个挺有意思的东西。

基准测试是什么

基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。
例如，对计算机CPU进行浮点运算、数据访问的带宽和延迟等指标的基准测试，可以使用户清楚地了解每一款CPU的运算性能及作业吞吐能力是否满足应用程序的要求；再如对数据库管理系统的ACID（Atomicity, Consistency, Isolation, Durability, 原子性、一致性、独立性和持久性）、查询时间和联机事务处理能力等方面的性能指标进行基准测试，也有助于使用者挑选最符合自己需求的数据库系统。

通过基准测试我们可以了解某个软件在给定环境下的性能表现，对使用者而言可以用作选型的参考，对开发者而言可以作为后续改进的基本参照。

JMH是什么

JMH（Java Microbenchmark Harness）是Java用来做基准测试一个工具，该工具由openJDK提供并维护，测试结果可信度较高，该项目官方还在持续更新中。

下面只是JMH简单描述，正所谓“纸上得来终觉浅，绝知此事要躬行”，要想全面了解还得读完官方给出的Demo或者看我的翻译注解版本的官方Demo。

已经给标题加链接，直接戳标题即可闪现到例子。官方例子有37个，这里只列出了梗概。

举个例子

功能入门第一课，Hello World！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class JMHSample_01_HelloWorld {

    @Benchmark
    public void wellHelloThere() {
        // this method was intentionally left blank.
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                // 指明本次要跑的类
                .include(JMHSample_01_HelloWorld.class.getSimpleName())
                // fork JVM的数量
                .forks(1)
                .build();

        new Runner(opt).run();
    }

}

看下输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# JMH version: 1.21
# VM version: JDK 1.8.0_74, Java HotSpot(TM) 64-Bit Server VM, 25.74-b02
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/bin/java
# VM options: -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=51264:/Applications/IntelliJ IDEA.app/Contents/bin -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.cxd.benchmark.JMHSample_01_HelloWorld.wellHelloThere

# 运行过程的输出
# Run progress: 0.00% complete, ETA 00:01:40
# Fork: 1 of 1
# Warmup Iteration   1: 2924740803.993 ops/s
# Warmup Iteration   2: 2916472711.387 ops/s
# Warmup Iteration   3: 3024204715.897 ops/s
# Warmup Iteration   4: 3051723946.668 ops/s
# Warmup Iteration   5: 2924014544.301 ops/s
Iteration   1: 2909665054.710 ops/s
Iteration   2: 2989675862.826 ops/s
Iteration   3: 2965046292.629 ops/s
Iteration   4: 3020263765.220 ops/s
Iteration   5: 2929485177.735 ops/s

# 当前方法测试结束的报告
Result "com.cxd.benchmark.JMHSample_01_HelloWorld.wellHelloThere":
  2962827230.624 ±(99.9%) 171803440.922 ops/s [Average]
  (min, avg, max) = (2909665054.710, 2962827230.624, 3020263765.220), stdev = 44616808.022
  CI (99.9%): [2791023789.702, 3134630671.547] (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.

# 所有benchmark跑完后的最终报告
Benchmark                                Mode  Cnt           Score           Error  Units
JMHSample_01_HelloWorld.wellHelloThere  thrpt    5  2962827230.624 ± 171803440.922  ops/s

上面的报告显示，我们用1个线程对吞吐量测量，测量和预热分别迭代了5次，最终得出的Score（ops/s）是2962827230.624 ± 171803440.922，测量过程中没有出现Error。

测试控制

测试输出结果中开头的配置项都是我们可以通过注解、编程或者命令行的方式来控制的。它可以具体到每个benchmark。

  • @Fork 需要运行的试验(迭代集合)数量。每个试验运行在单独的JVM进程中。也可以指定(额外的)JVM参数。

  • @Measurement 提供真正的测试阶段参数。指定迭代的次数，每次迭代的运行时间和每次迭代测试调用的数量(通常使用@BenchmarkMode(Mode.SingleShotTime)测试一组操作的开销——而不使用循环)

  • @Warmup 与@Measurement相同，但是用于预热阶段

  • @Threads 该测试使用的线程数。默认是Runtime.getRuntime().availableProcessors()

测试维度

通过JMH提供的工具我们可以轻松的的获得某个功能的吞吐量、平均运行时间、冷启动等指标的数据。

这些输出结果通过@BenchmarkMode注解来控制，它的值定义在枚举类org.openjdk.jmh.annotations.Mode中。

@BenchmarkMode接受的参数是一个Mode数据，也就是说，我们可以指定一个或者多个Mode，测试时会把我们指定的模式依次运行，打印出结果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public enum Mode {

    /**
     * <p>Throughput: operations per unit of time.</p>
     * 
     * 计算一个时间单位内操作数量
     */
    Throughput("thrpt", "Throughput, ops/time"),

    /**
     * <p>Average time: average time per per operation.</p>
     *
     * 计算平均运行时间
     */
    AverageTime("avgt", "Average time, time/op"),

    /**
     * <p>Sample time: samples the time for each operation.</p>
     *
     * 计算一个方法的运行时间(包括百分位)
     */
    SampleTime("sample", "Sampling time"),

    /**
     * <p>Single shot time: measures the time for a single operation.</p>
     *
     * 方法仅运行一次(用于冷测试模式)
     * 或者特定批量大小的迭代多次运行(具体查看的“`@Measurement“`注解)——这种情况下JMH将计算批处理运行时间(一次批处理所有调用的总时间)
     */
    SingleShotTime("ss", "Single shot invocation time"),

    /**
     * Meta-mode: all the benchmark modes.
     * 所有模式依次运行
     */
    All("all", "All benchmark modes"),
    ;
	
	// 省略...
}

数据的共享

测试的时候，我们可能需要向测试方法传入若干参数，这些参数还可能需要不同的隔离级别：每个线程单独一份还是每个benchmark一份还是一组线程共享等。

这些参数有以下要求：

  • 有无参构造函数(默认构造函数)
  • 是公共类
  • 内部类应该是静态的
  • 该类必须使用@State注解

参数必须是对象，因为@State被定义为ElementType.TYPE，即：可以用来注解类、接口或者枚举。

@State接受单个配置值Scope。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public enum Scope {

    /**
     * <p>Benchmark state scope.</p>
     *
     * 运行相同测试的所有线程将共享实例。
     * 可以用来测试状态对象的多线程性能(或者仅标记该范围的基准)。
     */
    Benchmark,

    /**
     * <p>Group state scope.</p>
     *
     * 实例分配给每个线程组(查看后面的测试线程组)
     */
    Group,

    /**
     * <p>Thread state scope.</p>
     *
     * 实例将分配给运行给定测试的每个线程。
     *
     */
    Thread,

}

数据的准备

数据的准备像极了JUnit和TestNG的方式，即：在测试开始前后分别进行处理。在JMH中对应到@Setup和@TearDown，我们可以在被进行标记的方法中对数据进行处理，并且处理的耗时不被记入正常测试的时间，也就是说不会影响我们测试结果。

@Setup和@TearDown分别接受单个配置值Level。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public enum Level {

    /**
     * Trial level: to be executed before/after each run of the benchmark.
     *
     * 在每个benchmark之前/之后运行
     */
    Trial,

    /**
     * Iteration level: to be executed before/after each iteration of the benchmark.
     *
     * 在一次迭代之前/之后(一组调用)运行
     */
    Iteration,

    /**
     * Invocation level: to be executed for each benchmark method execution.
     *
     * 每个方法调用之前/之后
     * 该方式较为复杂，在没有搞清楚之前，不要使用。
     */
    Invocation,
    ;
}

测试线程组

我们可以通过指定线程组的的方式来模拟一些场景，比如：生产-消费。这种场景下生产消费的线程数量往往是不一致的，通过@Group和@GroupThreads我们可以很轻松的制造出这种场景。

具体的使用说明例子中说的很详细 —-传送门—-> JMHSample_15_Asymmetric

编译器的控制

我们知道编译器在编译时会做一些优化，这个例子展示了如何用@CompilerControl来控制编译对方法内敛优化的控制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public @interface CompilerControl {

    /**
     * Compilation mode.
     */
    enum Mode {

        /**
         * Insert the breakpoint into the generated compiled code.
         */
        BREAK("break"),

        /**
         * Print the method and it's profile.
         */
        PRINT("print"),

        /**
         * Exclude the method from the compilation.
         * 不编译该方法 —— 用解释替代。
         */
        EXCLUDE("exclude"),

        /**
         * Force inline.
         * 要求编译器内嵌该方法。
         */
        INLINE("inline"),

        /**
         * Force skip inline.
         * 该方法不能被内嵌。用于测量方法调用开销和评估是否该增加JVM的inline阈值
         */
        DONT_INLINE("dontinline"),

        /**
         * Compile only this method, and nothing else.
         * 仅编译被注解的方法，其他的不编译。
         */
        COMPILE_ONLY("compileonly"),;
    }

}

基准测试中建议

编译器还有其他一些优化行为，常见的包括（更多参见）：死代码消除（DCE）、方法内敛（method inline）、循环优化、常量折叠。

方法内敛可以用上面提到的注解做控制，但更多的需要我们在些测试时采用一些小技巧规避，比如：DCE可以根据情况采用Blackhole消费输出结果。

  • 测试前后较重的处理放在@Setup和@TearDown中

  • 注意DCE（死代码消除）

  • 不出现循环被编译器优化，具体建议参考JMHSample_34_SafeLooping

  • 测试必须为fork，fork是分离出来子进程进行测试，@fork(2)含义为顺次（one-by-one）fork出子进程来测试

  • 使用@fork多次fork测试，减少运行间差异

  • 多线程测试时参考JMHSample_17_SyncIterations

  • 对非循环方法需要测量冷启动的时间消耗，参考JMHSample_26_BatchSize

  • 可以通过profiler获得基准测试时JVM的相关信息，比如栈、gc、classloader。参考JMHSample_35_Profilers

  • 在使用profiler时遇到no tty present and no askpass program specified错误是因为帐号并没有开启sudo免密导致的。
    通过以下步骤可解决，但测试完成后安全起见建议删除：sudo visudo；在文件最后追加 userName ALL=(ALL) NOPASSWD:ALL

知识点记录

编译优化

常见的编译器优化包括（更多参见）：死代码消除（DCE）、方法内敛（method inline）、循环优化、常量折叠。

方法内敛

许多优化手段都试图消除机器级跳转指令（例如，x86架构的JMP指令）。跳转指令会修改指令指针寄存器，因此而改变了执行流程。
相比于其他汇编指令，跳转指令是一个代价高昂的指令，这也是为什么大多数优化手段会试图减少甚至是消除跳转指令。
内联是一种家喻户晓而且好评如潮的优化手段，这是因为跳转指令代价高昂，而内联技术可以将经常调用的、具有不容入口地址的小方法整合到调用方法中。
Listing 3到Listing 5中的Java代码展示了使用内联的用法。

Listing 3. Caller method

1
2
3
int whenToEvaluateZing(int y) {
  return daysLeft(y) + daysLeft(0) + daysLeft(y+1);
}

Listing 4. Called method
1
2
3
4
5
6
int daysLeft(int x){
  if (x == 0)
     return 0;
  else
     return x - 1;
}

Listing 5. Inlined method
1
2
3
4
5
6
7
8
9
int whenToEvaluateZing(int y){
  int temp = 0;

  if(y == 0) temp += 0; else temp += y - 1;
  if(0 == 0) temp += 0; else temp += 0 - 1;
  if(y+1 == 0) temp += 0; else temp += (y + 1) - 1;

  return temp;
}

在Listing 3到Listing 5的代码中，展示了将调用3次小方法进行内联的示例，这里我们认为使用内联比跳转有更多的优势。

如果被内联的方法本身就很少被调用的话，那么使用内联也没什么意义，但是对频繁调用的“热点”方法进行内联在性能上会有很大的提升。

此外，经过内联处理后，就可以对内联后的代码进行进一步的优化，正如Listing 6中所展示的那样。

Listing 6. After inlining, more optimizations can be applied

1
2
3
4
5
int whenToEvaluateZing(int y){
  if(y == 0) return y;
  else if (y == -1) return y - 1;
  else return y + y - 1;
}

unrolled loop 循环展开
1
2
for (i = 1; i <= 60; i++)
   a[i] = a[i] * b + c;

可以如此循环展开：

1
2
3
4
5
6
for (i = 1; i <= 20; i+=3)
{
  a[i] = a[i] * b + c;
  a[i+1] = a[i+1] * b + c;
  a[i+2] = a[i+2] * b + c;
}

分支预测

底层对循环中判断的优化。简单理解，对执行的循环判断做采样，根据采样来预测下一个判断会走到哪个分支中。

参考这篇文章—->深入理解CPU的分支预测(Branch Prediction)模型<—-做进一步了解。

小生不才，以上如有描述有误的地方还望各位不吝赐教 !^_^！

参考资料

编译器的优化
方法内敛
什么是基准测试
JMH官方Demo
JHM官网
JMH简介-译文 —-> 英文原文