简介

应用过JMH的同学肯定会惊叹它的神奇。JMH作为一个优良的Benchmark框架带给了咱们有数的欢畅。作为一个有极客精力的程序员，那么有没有想过来本人实现一个Benchmark框架呢？

在实现Benchmark框架的时候有须要留神些什么问题呢？快来一起看看吧。

八条军规

这里叫军规实际上不适合，只是借用一下军规的来彰显一下声势！大家不要太介意。

第一条军规

工欲善其事，必先利其器。想写好一个JMH当然须要深刻理解JVM的运行原理，包含JIT，C1，C2编译器和他们的分层编译原理，JIT运行时的编译优化，包含Loop unrolling, Inlining, Dead Code Elimination,
Escape analysis, Intrinsics, Branch prediction等等。

当然，最好是参考一下大牛们写过的JMH框架，找点灵感。

最初大家要理解，Benchmark框架不是万能的。它只是在特定的环境中JVM的体现。

因为在Benchmark中咱们必定是要做循环的，一般来说就是某某办法运行多少次，这种比较简单的循环。实际上，JVM运行的代码是非常复杂的。Benchmark远远不能代表JVM的全副。

然而，见微知著，应用Benchmark还是能够一窥JVM的机密的。

第二条军规

在JMH中，咱们个别须要设置warmup和measurement的次数：

@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)

这是为什么呢？咱们晓得JIT中的代码是动静编译成为机器码的，并且是须要肯定的工夫的。

只有JIT检测到你这是热点代码，才会对其进行优化。

咱们检测代码的性能，个别是指代码在稳固运行的环境中的情景。而不是指第一次或者前几次运行的时候，因为这个时候，这些代码可能并没有被编译成机器码。这样的进去的后果往往是和理论不相符的。

第三条军规

在编写Benchmark的同时，肯定要开启JVM的日志。例如： -XX:+PrintCompilation, -verbose:gc等。

为什么呢？

大家想想benchmark是做什么的呢？就是统计工夫的。

咱们心愿在运行benchmark的时候，JVM不要做任何不属于运行代码的任何事件，否则就可能会影响到benchmark的准确性。

所以开启JVM的日志就是为了做校验。不要在做benchmark的时候有其余操作。

第四条军规

留神JIT的分层编译。

因为Client VM和Server VM的呈现，所以在JIT中呈现了两种不同的编译器，C1 for Client VM， C2 for Server VM。

因为javac的编译只能做大量的优化，其实大量的动静优化是在JIT中做的。C2绝对于C1，其优化的水平更深，更加激进。

为了更好的晋升编译效率，JVM在JDK7中引入了分层编译Tiered compilation的概念。

对于JIT自身来说，动静编译是须要占用用户内存空间的，有可能会造成较高的提早。

对于Server服务器来说，因为代码要服务很多个client，所以磨刀不误砍柴工，短暂的提早带来永恒的收益，听起来是能够承受的。

Server端的JIT编译也不是立马进行的，它可能须要收集到足够多的信息之后，才进行编译。

而对于Client来说，提早带来的性能影响就须要进行思考了。和Server相比，它只进行了简略的机器码的编译。

为了满足不同档次的编译需要，于是引入了分层编译的概念。

大略来说分层编译能够分为三层：

  1. 第一层就是禁用C1和C2编译器，这个时候没有JIT进行。
  2. 第二层就是只开启C1编译器，因为C1编译器只会进行一些简略的JIT优化，所以这个能够应答惯例状况。
  3. 第三层就是同时开启C1和C2编译器。

在JDK7中，你能够应用上面的命令来开启分层编译：

-XX:+TieredCompilation

而在JDK8之后，祝贺你，分层编译曾经是默认的选项了，不必再手动开启。

Client编译和Server编译，甚至是OSR都是不同的。大家在写Benchmark的时候肯定要留神。

第五条军规

留神初始化对性能的影响。

如果须要加载类，肯定要在warmup的阶段进行加载，除非你是想去测试加载的工夫。否则会对测试后果有影响。

同时也不要计算第一次print的工夫，因为print也会加载和初始化一些类。

第六条军规

要留神反优化和重编译的影响。

JIT在上面的几个非凡的状况下，须要对代码进行返优化：

有些非凡的状况上面，的确是须要进行反优化的。

上面是比拟常见的状况：

  1. 须要调试的状况

如果代码正在进行单个步骤的调试，那么之前被编译成为机器码的代码须要反优化回来，从而可能调试。

  1. 代码废除的状况

当一个被编译过的办法，因为种种原因不可用了，这个时候就须要将其反优化。

  1. 优化之前编译的代码

有可能呈现之前优化过的代码可能不够完满，须要从新优化的状况，这种状况下同样也须要进行反优化。

重编译是指JIT可能会从新优化代码，导致从新编译。

所以这条规定要求咱们warmup的工夫要尽可能的长。以便让JIT充沛优化。

第七条军规

在应用benchMark得出结论之前，肯定要去认真的了解JVM的底层代码（Assembly code），找到其景象的实质。

千万不要激动的下结论。最好是应用可视化的工具来剖析。比如说jitwatch。

最初一条军规

在测试的时候肯定要防止其余程序的影响 。

比如说两次测试，第一次测试是单机运行，第二次测试是在有其余服务正在运行的状况下进行的。

很显然这两次的后果是不能做比拟的。咱们须要多运行，剔除乐音后果。

总结

把握下面几条规定，置信大家也可能写出属于本人的Benchmarks。

本文链接：http://www.flydean.com/how-to-write-benchmarks/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」,懂技术，更懂你！