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
(足够大的)equals Xms
并使用 UseEpsilonGC
(如果可用)。
规则 8: 使用库进行基准测试,因为它可能更高效,并且已经为此目的进行了调试。例如 JMH , Caliper or Bill 和 Paul 的 Excellent UCSD Benchmarks for Java .