您如何在 Java 中编写(和运行)正确的微基准测试?
我正在寻找一些代码示例和注释来说明需要考虑的各种问题。
示例:基准测试应该测量时间/迭代还是迭代/时间,为什么?
最佳答案
关于编写微基准测试的提示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
标志报告 OSR 编译,带有一个 at 符号以表示非初始入口点,例如: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 .
关于java - 如何在 Java 中编写正确的微基准测试?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/504103/