使用 JMH 做 Java 微基准测试
在使用 Java 编程过程中,我们对于一些代码调用的细节有多种编写方式,但是不确定它们性能时,往往采用重复多次计数的方式来解决.但是随着 JVM 不断的进化,随着代码执行次数的增加,JVM 会不断的进行编译优化,使得重复多少次才能够得到一个稳定的测试结果变得让人疑惑,这时候有经验的同学就会在测试执行前先循环上万次并注释为预热.
没错!这样做确实可以获得一个偏向正确的测试结果,但是我们试想如果每到需要斟酌性能的时候,都要根据场景写一段预热的逻辑吗?当预热完成后,需要多少次迭代来进行正式内容的测量呢?每次测试结果的输出报告是不是都需要用 System.out 来输出呢?
其实这些工作都可以交给 JMH (the Java Microbenchmark Harness) ,它被作为 Java9 的一部分来发布,但是我们完全不需要等待 Java9,而可以方便的使用它来简化我们测试,它能够照看好 JVM 的预热,代码优化,让你的测试过程变得更加简单.
开始
首先在项目中新增依赖,jmh-core 以及 jmh-generator-annprocess 的依赖可以在 maven 仓库中找寻最新版本.
创建一个 Helloworld 类,里面只有一个空方法 m(),标注了 @Benchmark 的注解,声明这个方法为一个微基准测试方法,JMH 会在编译期生成基准测试的代码,并运行它.
接着添加一个 main 入口,由它来启动测试.
简单介绍一下这个 HelloworldRunner,它是一个入口的同时还完成了 JMH 测试的配置工作.默认场景下,JMH 会找寻标注了 @Benchmark 类型的方法,可能会跑一些你所不需要的测试,这样就需要通过 include 和 exclude 两个方法来完成包含以及排除的语义.
warmupIterations(10) 的意思是预热做 10 轮,measurementIterations(10) 代表正式计量测试做 10 轮,而每次都是先执行完预热再执行正式计量,内容都是调用标注了 @Benchmark 的代码.
forks(3) 指的是做 3 轮测试,因为一次测试无法有效的代表结果,所以通过 3 轮测试较为全面的测试,而每一轮都是先预热,再正式计量.
我们运行 HelloworldRunner,经过一段时间,测试结果如下:
可以看到分数是 30 亿次,但是这 30 亿指的是什么呢?仔细观察 Mode 一项中类型是 thrpt,其实就是 Throughput 吞吐量,代表着每秒完成的次数.
测试类型
前面提到测试的类型是吞吐量,也就是一秒钟调用完成的次数,但是如果想知道做一次需要多少时间该怎么办?
其实 1 / 吞吐量 就是这个值
JMH 提供了以下几种类型进行支持:
使用这些模式也非常简单,只需要增加 @BenchmarkMode 注解即可,例如:
配置策略
JMH 支持通过 @Fork 注解完成配置,例如:
以上注解指 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 百万次迭代.
接着是逆向循环,次数也是 1 百万次.
最后是一个测试的入口,我们采用 3 组,每组预热 10 轮,正式计量 10 轮,测试类型是吞吐量.
测试结果如下,有数据表现可以看到逆序在宏观上是优于正序的.
优化的 Hessian2 微基准测试
HSF 默认使用 Hessian2 进行序列化传输,而 Hessian2 在传输时,每次会捎带上类型元信息,这些在实际场景下对资源会产生一定的开销.HSF2.2 会使用优化的 Hessian2 进行序列化,与 Hessian2 的不同在于,它会基于长连接级别缓存元信息,每次只会发送数据内容,由于只发送数据内容,所以资源开销会更少,我们对 Hessian2 和优化后的 Hssian2 做了基准测试,结果如下:
优化后的 hessian 在序列化吞吐量上领先 hessian2,达到每秒 17W,反序列化出乎意料,超过 hessian2 两倍,达到 32W 每秒.
来源: http://www.jianshu.com/p/09837e2b4408