原文地址: https://lcy362.github.io/posts/4987/
有时候我们需要写一些简单的性能测试代码，恰好在stackoverflow上看到一篇经验之谈，https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java， 怎样写基准测试来尽量屏蔽掉环境的影响。
翻译出来贴在这儿：
来自Java HotSpot作者的撰写微基准的提示：
规则0：阅读有关JVM和微型基准测试的好论文。比如https://www.ibm.com/developerworks/java/library/j-jtp02225/。不要对这种测试有太高的期望;它们对JVM性能的测试仅能起到有限效果。
规则1：始终包含一个预热阶段，它一直运行，直到触发所有的初始化和编译。 （预热阶段的迭代次数可以减少，经验法则是几万次循环。）
规则2：始终使用-XX:+PrintCompilation -verbose:gc 等参数来运行，这样可以确定编译阶段和JVM的其他部分在计时时是否进行了一些意外的工作。
规则2.1：在计时和预热阶段的开始和结束打印消息，这样可以确定计时时是否有规则2的输出。
规则3：了解-client与-server之间的区别，还有OSR和常规汇编之间的区别。 -server优于-client, 常规编译优于OSR
规则4：注意初始化的影响，第一次计时不要打印结果，除非是在测试类加载的过程，规则2是你对抗这种效果的第一道防线。
规则5：注意编译器优化和重新编译的效果。计时时不要使用任何代码路径，因为编译器可能会基于一些乐观假设进行优化，导致根本不会使用该路径，从而可以对代码进行垃圾和重新编译。规则2是你对抗这种效果的第一道防线。
规则6：使用适当的工具读取编译器的工作过程，并对它产生一些令人惊讶的代码做好。在形成关于什么使事情更快或更慢的理论之前自己检查代码。
规则7：减少测量中的噪音。在一台安静的机器上运行基准测试，并运行几次，抛弃异常值。使用-Xbatch将编译器与应用程序串行化，并考虑设置 -XX：CICompilerCount = 1以防止编译器与其自身并行运行。
规则8：使用一些库用来做基准测试，因为它可能更有效率。比如JMH，Caliper，UCSD Benchmarks for Java等。