如何在Java中编写(并运行)正确的微基准？

我正在寻找一些代码示例和注释，说明需要考虑的各种问题。

示例：基准应该度量时间/迭代还是迭代/时间，为什么？

相关：是否接受秒表基准测试？

从Java热点创作者编写微基准的技巧

规则0：阅读一篇关于JVM和微观基准的著名论文。一个好的例子是Brian Goetz，2005年。不要对微观基准期望太高；它们只测量有限范围的JVM性能特性。

规则1：始终包含一个预热阶段，该阶段一直运行测试内核，足以在计时阶段之前触发所有初始化和编译。(在预热阶段，可以减少迭代次数。经验法则是数万次内部循环迭代。)

规则2：总是使用-XX:+PrintCompilation和-verbose:gc等运行，这样您就可以验证编译器和JVM的其他部分在您的计时阶段没有做意外的工作。

规则2.1：在计时和预热阶段的开始和结束时打印消息，以便您可以验证在计时阶段没有来自规则2的输出。

规则3：注意-client和-server的区别，以及osr和常规汇编。-XX:+PrintCompilation标志报告带有at符号的OSR编译，以表示非初始入口点，例如：Trouble$1::run @ 2 (41 bytes)。如果您追求最好的性能，那么您更喜欢服务器而不是客户机，更喜欢常规的OSR。

规则4：注意初始化效果。不要在计时阶段第一次打印，因为打印会加载并初始化类。不要在预热阶段(或最终报告阶段)之外加载新类，除非您专门测试类加载(在这种情况下，只加载测试类)。规则2是你对这种影响的第一道防线。

规则5：注意去优化和重新编译的效果。在计时阶段，不要第一次使用任何代码路径，因为编译器可能会基于先前乐观的假设(即根本不会使用该路径)，对代码进行垃圾处理和重新编译。规则2是你对这种影响的第一道防线。

规则6：使用适当的工具阅读编译器的思想，并期望对它生成的代码感到惊讶。在形成使事情更快或更慢的理论之前，先检查代码。

规则7：减少测量中的噪音。在一台安静的机器上运行基准测试，并运行几次，丢弃异常值。使用-Xbatch将编译器与应用程序一起序列化，并考虑设置-XX:CICompilerCount=1以防止编译器与自身并行运行。尽量减少GC开销，将EDOCX1(足够大)设置为Xms，如果可用，则使用UseEpsilonGC。

规则8：为基准使用一个库，因为它可能更有效，并且已经为此目的进行了调试。如JMH、Calpor或比尔和保罗优秀的UCSD基准Java。

我知道这个问题被标记为已被回答，但我想提及两个帮助我们编写微基准测试的库。

来自谷歌的卡尺

入门教程

来自OpenJDK的JMH

入门教程

Java基准的重要内容是：

• 在计时之前，先运行代码几次，预热JIT
• 确保运行足够长的时间，以便能够在几秒钟或(更好)十秒钟内测量结果。
• 虽然您不能在迭代之间调用System.gc()，但是最好在测试之间运行它，这样每个测试都有可能得到一个"干净"的内存空间。(是的，gc()更像是一种暗示，而不是保证，但根据我的经验，它很可能真的会被垃圾收集。)
• 我喜欢显示迭代和时间，以及可以缩放的时间/迭代分数，以便"最佳"算法的得分为1.0，其他算法的得分相对。这意味着您可以长时间运行所有算法，同时改变迭代次数和时间，但仍然可以获得可比较的结果。

我正在写一篇关于.NET基准框架设计的博客。我有几个早期的帖子可以给你一些建议，当然不是每件事都是合适的，但其中一些可能是合适的。

JMH是OpenJDK的一个新成员，由Oracle的一些性能工程师编写。当然值得一看。

The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.

隐藏在样本测试注释中的非常有趣的信息片段。

参见：

• 避免JVM上的基准测试陷阱
• 讨论JMH的主要优势。

Should the benchmark measure time/iteration or iterations/time, and why?

这取决于你想测试什么。

如果您对延迟感兴趣，请使用时间/迭代；如果您对吞吐量感兴趣，请使用迭代/时间。

确保以某种方式使用以基准代码计算的结果。否则，您的代码可以被优化掉。

如果您试图比较两种算法，请为每种算法至少做两个基准点，交替顺序。即。：

我发现在同一个算法的运行时，在不同的过程中有一些明显的差异(有时5-10%)。

另外，确保n非常大，这样每个循环的运行时间至少为10秒左右。迭代次数越多，基准时间内的数据越重要，数据越可靠。

在Java中编写微基准有很多可能的缺陷。

首先：您必须使用或多或少随机花费时间的各种事件进行计算：垃圾收集、缓存效果(文件的操作系统和内存的CPU)、IO等。

第二：对于非常短的时间间隔，您不能相信测量时间的准确性。

第三：JVM在执行时优化代码。因此，同一个JVM实例中的不同运行将变得越来越快。

我的建议是：让您的基准运行几秒钟，这比运行时间超过几毫秒更可靠。预热JVM(意味着在不进行测量的情况下至少运行一次基准，JVM可以运行优化)。并多次运行基准(可能是5次)，取中值。在一个新的JVM实例中运行每一个微基准(调用每一个基准新Java)，否则JVM的优化效果会影响以后运行的测试。不要执行那些在预热阶段没有执行的东西(因为这可能触发类加载和重新编译)。

还应该注意的是，在比较不同的实现时，分析微基准的结果也可能很重要。因此，应进行显著性检验。

这是因为在基准测试的大部分运行期间，实现A可能比实现B更快。但A的分布也可能更大，因此与B相比，A的实测性能效益没有任何意义。

因此，正确地编写和运行一个微基准也很重要，同时正确地分析它也是很重要的。

除此之外，我还要注意以下几点：

对于某些CPU(例如带TurboBoost的Intel Core i5系列)，温度(以及当前使用的内核数量以及更高的利用率百分比)会影响时钟速度。由于CPU是动态时钟的，这可能会影响您的结果。例如，如果您有单线程应用程序，则最大时钟速度(使用TurboBoost)高于使用所有核心的应用程序。因此，这会干扰某些系统上单线程和多线程性能的比较。请记住，温度和挥发物也会影响涡轮频率保持的时间。

也许是一个更重要的方面，你可以直接控制：确保你测量的是正确的东西！例如，如果您使用System.nanoTime()对特定代码位进行基准测试，请将对分配的调用放在有意义的地方，以避免测量您不感兴趣的内容。例如，不要这样做：

问题是，代码完成后，您不能立即获得结束时间。相反，请尝试以下操作：

HTTP://optSooSoCurgE.NET/Java微基准——确定不同平台上计算机系统的比较性能特征所需的控制任务。可以用来指导优化决策和比较不同的Java实现。