java hotspot创建者编写微基准测试的技巧：
规则0：阅读一篇关于JVM和微观基准测试的著名论文。一个好的例子是brian goetz，2005年。不要对微观基准期望太高；它们只测量有限范围的jvm性能特征。
规则1：始终包括一个预热阶段，该阶段将一直运行测试内核，足以在计时阶段之前触发所有初始化和编译(在热身阶段，较少的迭代是可以的。经验法则是数万次内部循环迭代。）
规则2：始终与 -XX:+PrintCompilation , -verbose:gc ，以便您可以验证编译器和jvm的其他部分在计时阶段没有执行意外的工作。
规则2.1：在计时和预热阶段的开始和结束时打印消息，以便您可以验证计时阶段没有规则2的输出。
规则3：意识到 -client 及 -server ，以及osr和定期汇编。这个 -XX:+PrintCompilation flag使用at符号报告osr编译，以表示非初始入口点，例如： Trouble$1::run @ 2 (41 bytes) . 如果您追求最佳性能，则更喜欢服务器而不是客户端，更喜欢常规而不是osr。
规则4：注意初始化效果。不要在计时阶段第一次打印，因为打印会加载和初始化类。不要在预热阶段（或最终报告阶段）之外加载新类，除非您专门测试类加载（在这种情况下，只加载测试类）。规则2是你对抗这些影响的第一道防线。
规则5：注意去优化和重新编译的效果。不要在计时阶段第一次使用任何代码路径，因为编译器可能会根据之前的乐观假设（即根本不会使用该路径）垃圾并重新编译代码。规则2是你对抗这些影响的第一道防线。
规则6：使用适当的工具来了解编译器的想法，并期望对它生成的代码感到惊讶。在形成关于是什么使事情更快或更慢的理论之前，自己检查代码。
规则7：减少测量中的噪音。在一台安静的机器上运行基准测试，并运行几次，丢弃异常值。使用 -Xbatch 将编译器与应用程序序列化，并考虑设置 -XX:CICompilerCount=1 防止编译器与其自身并行运行。尽量减少gc开销，设置 Xmx （足够大）等于 Xms 和使用 UseEpsilonGC 如果可以的话。
规则8：将库用于基准测试，因为它可能更有效，并且已经为此目的进行了调试。例如jmh、caliper或bill和paul的优秀ucsd java基准测试。

我知道这个问题已经被标记为已回答，但我想提到两个库，它们帮助我们编写微基准测试
谷歌卡尺
入门教程
http://codingjunkie.net/micro-benchmarking-with-caliper/
http://vertexlabs.co.uk/blog/caliper
来自openjdk的jmh
入门教程
避免jvm上的基准测试陷阱
使用jmh进行java微基准标记
jmh简介

java基准测试的重要内容包括：
在对jit进行计时之前，先运行几次代码来预热jit
确保运行足够长的时间，以便能够在几秒钟或（更好的）几十秒钟内测量结果
当你不能打电话的时候 System.gc() 在迭代之间，最好在测试之间运行它，这样每个测试都有希望获得一个“干净”的内存空间(对 gc() 这更像是一种暗示，而不是一种保证，但根据我的经验，它很可能真的会被垃圾收集。）
我喜欢显示迭代和时间，以及可以缩放的时间/迭代分数，以便“最佳”算法的分数为1.0，其他算法的分数相对较高。这意味着您可以在较长的时间内运行所有算法，改变迭代次数和时间，但仍然可以获得可比的结果。
我正在写关于.net中基准测试框架设计的博客。我之前的几篇帖子可能会给你一些想法——当然，不是所有的东西都是合适的，但其中一些可能是合适的。

jmh是openjdk的新成员，由oracle的一些性能工程师编写。当然值得一看。
jmh是一个java工具，用于构建、运行和分析用java和其他针对jvm的语言编写的nano/micro/macro基准。
样本测试注解中隐藏了非常有趣的信息。
另见：
避免jvm上的基准测试陷阱
讨论jmh的主要优势。

基准测试应该测量时间/迭代还是迭代/时间，为什么？
这取决于你想测试什么。
如果您对延迟感兴趣，请使用时间/迭代；如果您对吞吐量感兴趣，请使用迭代/时间。

如果您试图比较两种算法，请为每种算法至少做两个基准测试，交替顺序。即。：

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

我发现同一算法在不同过程中的运行时存在一些明显的差异（有时为5-10%）。。
另外，请确保n非常大，以便每个循环的运行时间至少为10秒左右。迭代次数越多，基准时间中的数字越重要，数据越可靠。

确保以某种方式使用在基准代码中计算的结果。否则，您的代码可以被优化掉。

用java编写微基准测试有许多可能的陷阱。
首先：你必须计算各种各样的事件，这些事件或多或少都是随机的：垃圾收集、缓存效果（文件的操作系统和内存的cpu）、io等等。
第二：在很短的时间间隔内，你不能相信测量时间的准确性。
第三：jvm在执行时优化代码。因此，同一jvm示例中的不同运行速度将越来越快。
我的建议是：让基准测试运行几秒钟，这比运行时间超过毫秒更可靠。预热jvm（意味着至少运行一次基准测试而不测量jvm是否可以运行优化）。然后运行您的基准多次（可能5次）并取中值。在新的jvm示例中运行每个微基准测试（调用每个基准测试新java），否则jvm的优化效果可能会影响以后运行的测试。不要执行在预热阶段没有执行的东西（因为这可能会触发类加载和重新编译）。

还应该注意，在比较不同的实现时，分析微基准测试的结果可能也很重要。因此，应进行显著性检验。
这是因为执行 A 在基准测试的大多数运行期间可能比实现更快 B . 但是 A 也可能有更高的价差，因此 A 与之相比没有任何意义 B .
因此，正确地编写和运行微基准测试也很重要，但正确地分析它也很重要。

除此之外，我还要注意以下几点：
对于某些CPU（例如带有turboboost的intel core i5系列），温度（和当前使用的内核数量，以及它们的利用率）会影响时钟速度。由于CPU是动态计时的，这可能会影响结果。例如，如果您有一个单线程应用程序，则最大时钟速度（使用turboboost）高于使用所有内核的应用程序。因此，这可能会干扰某些系统上单线程和多线程性能的比较。请记住，温度和电压也会影响涡轮频率保持的时间。
也许你可以直接控制一个更重要的方面：确保你测量的是正确的东西！例如，如果您正在使用 System.nanoTime() 要对特定的代码进行基准测试，请将对赋值的调用放在有意义的地方，以避免测量您不感兴趣的内容。例如，不要做：

long startTime = System.nanoTime();
//code here...
System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

问题是当代码完成时，您不能立即获得结束时间。相反，请尝试以下操作：

final long endTime, startTime = System.nanoTime();
//code here...
endTime = System.nanoTime();
System.out.println("Code took "+(endTime-startTime)+"nano seconds");

http://opt.sourceforge.net/ java微基准测试-确定不同平台上计算机系统的比较性能特征所需的控制任务。可以用来指导优化决策和比较不同的java实现。