有关从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编译时带有一个符号，以表示非初始入口点，例如：Trouble$1::run @ 2 (41 bytes)。如果您追求最佳性能，则优先选择服务器而不是客户端，并经常选择OSR。

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

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

规则6：使用适当的工具来阅读编译器的思想，并期望对其生成的代码感到惊讶。在形成有关使事物变快或变慢的理论之前，请自己检查代码。

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

规则8：将库用于基准测试，因为它可能更有效，并且已经针对此目的进行了调试。