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

【问题标题】：How do I write a correct micro-benchmark in Java?如何在 Java 中编写正确的微基准测试？
【发布时间】：2023-04-24 04:59:02
【问题描述】：

您如何在 Java 中编写（和运行）正确的微基准测试？

我正在寻找一些代码示例和 cmets 来说明需要考虑的各种事情。

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

【问题讨论】：

请参阅几分钟前的 [this question][1] 以获取一些相关信息。编辑：对不起，这不应该是一个答案。我应该发表评论。 [1]：*.com/questions/503877/…
Java 9 可能会为微基准测试提供一些功能：openjdk.java.net/jeps/230
@Raedwald 我认为 JEP 旨在为 JDK 代码添加一些微基准，但我认为 jmh 不会包含在 JDK 中...
@Raedwald 来自未来的你好。 It didn't make the cut.
请参阅：JMH, a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks 和 JEP 230: Microbenchmark Suite 并重复问题 Best approach for dealing with time measures?。

标签： java jvm benchmarking jvm-hotspot microbenchmark

【解决方案1】：

关于编写微基准测试的提示from the creators of Java HotSpot：

规则 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 开销，设置Xmx(足够大) 等于Xms 并使用UseEpsilonGC（如果可用）。

规则 8： 为您的基准测试使用库，因为它可能更有效，并且已经为此唯一目的进行了调试。如JMH、Caliper 或Bill and Paul's Excellent UCSD Benchmarks for Java。

【讨论】：

这也是一篇有趣的文章：ibm.com/developerworks/java/library/j-jtp12214
另外，切勿使用 System.currentTimeMillis() ，除非您对 + 或 - 15 毫秒的精度感到满意，这在大多数 OS + JVM 组合中很常见。请改用 System.nanoTime()。
javaOne 的一些论文：azulsystems.com/events/javaone_2009/session/…
需要注意的是，System.nanoTime() 并不保证比System.currentTimeMillis() 更准确。它只保证至少一样准确。然而，它通常更准确。
必须使用System.nanoTime()而不是System.currentTimeMillis()的主要原因是前者保证单调递增。减去两个 currentTimeMillis 调用返回的值实际上会产生否定结果，可能是因为系统时间已被某些 NTP 守护进程调整。

【解决方案2】：

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

Caliper from Google

入门教程

JMH from OpenJDK

入门教程

【讨论】：

+1 它可以作为已接受答案的规则 8 添加：规则 8：因为很多事情都可能出错，您可能应该使用现有的库而不是自己尝试！
@Pangea jmh 现在可能优于 Caliper，另请参阅：groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…

【解决方案3】：

Java 基准测试的重要事项是：

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

我正在撰写有关 .NET 基准测试框架设计的博客。我有一个 couple 或 earlier posts 可能会给你一些想法 - 当然，不是所有的东西都合适，但其中一些可能是合适的。

【讨论】：

次要的 nitpick：IMO “so that each test get”应该是“so that each test may get”，因为前者给人的印象是调用 gc always 可以释放未使用的内存。
@SanjayT.Sharma：嗯，意图是它确实做到了。虽然没有严格保证，但它实际上是一个非常强烈的提示。将编辑更清晰。
我不同意调用 System.gc()。这是一个提示，仅此而已。甚至没有“它有望做点什么”。你永远不应该调用它。这是编程，不是艺术。
@gyabraham：是的，这是一个提示——但我观察到这是一个通常被采用的提示。因此，如果您不喜欢使用System.gc()，您如何建议在一个测试中尽量减少由于先前测试中创建的对象而导致的垃圾收集？我是务实的，不是教条的。
@gyabraham：我不知道你所说的“伟大的后备”是什么意思。您能否详细说明一下 - 您是否有提供更好结果的建议？我确实明确表示这不是保证......

【解决方案4】：

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

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

隐藏在the sample tests comments中的非常有趣的信息。

另见：

【讨论】：

另请参阅这篇博文：psy-lob-saw.blogspot.com/2013/04/…，了解有关 JMH 入门的详细信息。
仅供参考，JEP 230: Microbenchmark Suite 是基于此Java Microbenchmark Harness (JMH) 项目的OpenJDK 提案。 Did not make the cut for Java 9 但以后可能会添加。

【解决方案5】：

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

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

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

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

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

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

【讨论】：

自然地改变顺序会影响运行时间。 JVM 优化和缓存效果将在这里发挥作用。更好的是“预热” JVM 优化，多次运行并在不同的 JVM 中对每个测试进行基准测试。
实际上我会说对于大多数基准测试你想要热身版本，我建议如果你运行 10 秒（根据上述建议），你只计算最后 5秒--扔掉前 5 个。记住 java 有时会编译代码。

【解决方案8】：

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

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

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

第三：JVM 在执行时优化你的代码。所以在同一个 JVM-instance 中不同的运行会越来越快。

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

【讨论】：

【解决方案9】：

还应注意，在比较不同的实现时，分析微基准测试的结果也可能很重要。因此应该创建一个significance test。

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

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

【讨论】：

【解决方案10】：

除了其他出色的建议之外，我还要注意以下几点：

对于某些 CPU（例如带有 TurboBoost 的 Intel Core i5 系列），温度（和当前使用的内核数量，以及它们的利用率百分比）会影响时钟速度。由于 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");

【讨论】：

是的，重要的是不要在定时区域内做无关的工作，但你的第一个例子仍然很好。只有一个对println 的调用，而不是单独的标题行或其他东西，并且System.nanoTime() 必须作为构造该调用的字符串arg 的第一步 进行评估。编译器对第一个没有什么是他们不能对第二个做的，甚至没有人鼓励他们在记录停止时间之前做额外的工作。

【解决方案11】：

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

【讨论】：

似乎只是对 JVM + 硬件进行基准测试，而不是任意一段 Java 代码。