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（足够大）equalsXms并UseEpsilonGC在可用时使用。

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