如何在Java中编写正确的微基准测试？

小开

Java基准的重要事项是：

首先通过多次运行代码来预热JIT在计时 it
确保你运行它足够长的时间，以便能够在几秒钟或（更好的）几十秒内测量结果
虽然你不能在迭代之间调用System.gc()，但在测试之间运行它是一个好主意，这样每个测试都有希望获得一个“干净”的内存空间来使用。（是的，gc()与其说是保证，不如说是暗示，但根据我的经验，它真的会垃圾收集。）
我喜欢显示迭代和时间，以及时间/迭代的分数，可以缩放，以便“最佳”算法获得1.0的分数，而其他算法以相对的方式得分。这意味着你可以运行所有算法很长时间，改变迭代次数和时间，但仍然得到可比的结果。

我正在写一篇关于. NET中基准测试框架设计的博客。我有一个夫妇以前的帖子，它可能会给你一些想法-当然，并非所有事情都合适，但其中一些可能是。

小开

在Java中编写微基准测试有许多可能的陷阱。

首先：您必须计算各种或多或少随机需要时间的事件：垃圾收集、缓存效果（文件的操作系统和内存的CPU）、IO等。

第二：你不能相信在很短的时间间隔内测量时间的准确性。

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

我的建议：让你的基准测试运行几秒钟，这比运行毫秒更可靠。预热JVM（意味着至少运行一次基准测试，而不测量，JVM可以运行优化）。并多次运行基准测试（也许5次），并取中值。在新的JVM实例中运行每个微基准测试（调用每个基准测试的新Java），否则JVM的优化效果会影响以后运行的测试。不要执行在预热阶段未执行的东西（因为这可能触发类加载和重新编译）。

小开

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

for(i=1..n)alg1();for(i=1..n)alg2();for(i=1..n)alg2();for(i=1..n)alg1();

我发现了一些明显的差异（5-10%有时）在运行时相同的算法在不同的通道。

此外，确保n非常大，以便每个循环的运行时间至少在10秒左右。迭代次数越多，基准时间中的重要数字就越多，数据就越可靠。

小开

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

小开

基准测试应该测量时间/迭代还是迭代/时间，为什么？

这取决于您要测试的什么。

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

小开

最佳答案

关于编写微基准测试来自JavaHotSpot的创建者的提示：

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

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

规则2：始终使用-XX:+PrintCompilation、-verbose:gc等运行，因此您可以验证编译器和JVM的其他部分在计时阶段没有执行意外的工作。

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

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

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

规则5：注意去优化和重新编译的影响。在计时阶段第一次不要使用任何代码path，因为编译器可能会垃圾化并重新编译代码，这是基于之前乐观的假设，即路径根本不会被使用。规则2是你抵御此类影响的第一道防线。

规则6：使用适当的工具来读懂编译器的心思，并期望对它生成的代码感到惊讶。在形成关于是什么让事情更快或更慢的理论之前，自己检查代码。

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

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

小开

http://opt.sourceforge.net/Java微基准-确定计算机系统在不同平台上的比较性能特征所需的控制任务。可用于指导优化决策和比较不同的Java实施。

小开

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

来自Google的卡尺

入门教程

JMH从OpenJDK

入门教程

小开

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

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

因此，正确编写和运行微基准测试也很重要，还要正确分析它。

小开

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

jmh是一个Java工具，用于构建、运行和分析以Java和其他语言编写的针对JVM的纳米/微/宏基准测试。

非常有趣的信息埋在示例测试评论中。

另见：

小开

为了补充其他优秀的建议，我还会注意以下几点：

对于某些CPU（例如英特尔酷睿i5系列的TurboBoost），温度（和当前正在使用的内核数量，以及它们的利用率百分比）会影响时钟速度。由于CPU是动态时钟的，这会影响您的结果。例如，如果您有一个单线程应用程序，最大时钟速度（使用TurboBoost）高于使用所有内核的应用程序。因此，这可能会干扰某些系统上单线程和多线程性能的比较。请记住，温度和电压也会影响Turbo频率保持的时间。

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

long startTime = System.nanoTime();//code here...System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

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

final long endTime, startTime = System.nanoTime();//code here...endTime = System.nanoTime();System.out.println("Code took "+(endTime-startTime)+"nano seconds");