如果你想写自己的Benchmark框架(推荐)

简介

使用过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相比，它只进行了简单的机器码的编译。

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

大概来说分层编译可以分为三层：

• 第一层就是禁用C1和C2编译器，这个时候没有JIT进行。
• 第二层就是只开启C1编译器，因为C1编译器只会进行一些简单的JIT优化，所以这个可以应对常规情况。
• 第三层就是同时开启C1和C2编译器。

在JDK7中，你可以使用下面的命令来开启分层编译：

-XX:+TieredCompilation

而在JDK8之后，恭喜你，分层编译已经是默认的选项了，不用再手动开启。

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

第五条军规

注意初始化对性能的影响。

如果需要加载类，一定要在warmup的阶段进行加载，除非你是想去测试加载的时间。否则会对测试结果有影响。

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

第六条军规

要注意反优化和重编译的影响。

JIT在下面的几个特殊的情况下，需要对代码进行返优化：

有些特殊的情况下面，确实是需要进行反优化的。

下面是比较常见的情况：

1.需要调试的情况

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

2.代码废弃的情况

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

3.优化之前编译的代码

有可能出现之前优化过的代码可能不够完美，需要重新优化的情况，这种情况下同样也需要进行反优化。

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

所以这条规则要求我们warmup的时间要尽可能的长。以便让JIT充分优化。

第七条军规

在使用benchMark得出结论之前，一定要去认真的理解JVM的底层代码（Assembly code），找到其现象的本质。

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

最后一条军规

在测试的时候一定要避免其他程序的影响 。

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

很显然这两次的结果是不能做比较的。我们需要多运行，剔除噪音结果。

总结

掌握上面几条规则，相信大家也能够写出属于自己的Benchmarks。

到此这篇关于如果你想写自己的Benchmark框架的文章就介绍到这了,更多相关Benchmark框架内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！