如何用Java编写(并运行)正确的微基准测试？
我正在寻找一些代码样本和注释，以说明需要考虑的各种事情.
示例:基准测试应该测量时间/迭代还是迭代/时间，为什么？
如何用Java编写(并运行)正确的微基准测试？
我正在寻找一些代码样本和注释，以说明需要考虑的各种事情.
示例:基准测试应该测量时间/迭代还是迭代/时间，为什么？
关于编写微基准的提示from the creators of Java HotSpot:
Rule 0:阅读一篇关于JVM和微观基准测试的著名论文.好的是Brian Goetz, 2005.不要对微观基准抱有太多期望；它们只测量有限范围的JVM性能特征.
Rule 1:始终包括一个预热阶段，该阶段一直运行测试内核，足以在计时阶段之前触发所有初始化和编译.(在热身阶段，较少的迭代是可以的.经验法则是数万次内循环迭代.)
Rule 2:总是与-XX:+PrintCompilation、-verbose:gc等一起运行，因此您可以验证编译器和JVM的其他部分在计时阶段没有执行意外的工作.
Rule 2.1:在计时和预热阶段开始和结束时打印消息，因此您可以验证在计时阶段没有来自规则2的输出.
Rule 3:注意-client和-server之间的区别，以及OSR和常规编译之间的区别.-XX:+PrintCompilation标志报告OSR编译，并使用at符号表示非初始入口点，例如:Trouble$1::run @ 2 (41 bytes).如果您追求最佳性能，请 Select 服务器而不是客户端， Select 常规而不是OSR.
Rule 4:请注意初始化效果.不要在计时阶段第一次打印，因为打印会加载和初始化类.不要在预热阶段(或最终报告阶段)之外加载新类，除非您专门测试类加载(在这种情况下，只加载测试类).规则2是你抵御这些影响的第一道防线.
Rule 5:注意反优化和重新编译的影响.不要在计时阶段第一次采用任何代码路径，因为编译器可能会基于先前乐观的假设，即该路径根本不会被使用，而对代码进行垃圾处理和重新编译.规则2是你抵御这种影响的第一道防线.
Rule 6:人使用适当的工具来解读编译器的 idea ，并期望对其生成的代码感到惊讶.在形成关于是什么让事情变得更快或更慢的理论之前，请自己判断代码.
Rule 7:减少你测量时的噪音.在一台安静的机器上运行您的基准测试，并多次运行它，go 掉异常值.使用-Xbatch将编译器与应用程序序列化，并考虑设置-XX:CICompilerCount=1以防止编译器与自身并行运行.尽量减少GC开销，将Xmx(足够大)设置为Xms，如果可用则使用UseEpsilonGC.
Rule 8:将库用于您的基准测试，因为它可能更高效，并且已经针对此唯一目的进行了调试.例如JMH、Caliper或Bill and Paul's Excellent UCSD Benchmarks for Java.