关于编写微基准from the creators of 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（足够大）设置为等于Xms，如果可用，则使用UseEpsilonGC。
**规则8:*使用一个库作为您的基准测试，因为它可能更高效，并且已经为此目的进行了调试。例如JMH、Caliper或Bill and Paul's Excellent UCSD Benchmarks for Java。

我知道这个问题已经被标记为已回答，但我想提到两个库，它们帮助我们编写微基准

Caliper from Google

• 入门教程*

1.http://codingjunkie.net/micro-benchmarking-with-caliper/
1.http://vertexlabs.co.uk/blog/caliper

JMH from OpenJDK

• 入门教程*

1.Avoiding Benchmarking Pitfalls on the JVM
1.Using JMH for Java Microbenchmarking
1.Introduction to JMH

Java基准测试的重要内容是：

• 在计时之前，先运行几次代码来预热JIT
• 确保运行足够长的时间，以便能够在几秒或（更好）几十秒内测量结果
• 虽然不能在迭代之间调用System.gc()，但最好在测试之间运行它，这样每个测试都有希望获得一个“干净”的内存空间。（是的，gc()更多的是一个提示，而不是一个保证，但根据我的经验，它很可能真的会进行垃圾收集。）
• 我喜欢显示迭代次数和时间，以及时间/迭代的分数，可以缩放，以便“最佳”算法得到1.0的分数，其他算法以相对方式评分。这意味着您可以在较长的时间内运行all算法，改变迭代次数和时间，但仍然可以获得可比较的结果。

我正在写关于.NET中基准框架设计的博客。我有一个couple的earlier posts，它可能会给你一些想法-当然，不是所有的东西都是合适的，但有些可能是合适的。

jmh是OpenJDK的最新添加，由Oracle的一些性能工程师编写。当然值得一看。
jmh是一个Java工具，用于构建、运行和分析以Java和其他语言编写的针对JVM的纳米/微/宏基准测试。
the sample tests comments中隐藏的非常有趣的信息片段。
另见：

• Avoiding Benchmarking Pitfalls on the 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的优化效果会影响以后运行的测试。不要执行在预热阶段没有执行的东西（因为这可能会触发类加载和重新编译）。

还应注意，在比较不同实现时，分析微基准测试的结果也可能很重要。因此，应制作significance test。
这是因为在基准测试的大多数运行期间，实现A可能比实现B更快。但A也可能具有更高的扩展，因此与B相比，A的测量性能优势没有任何意义。
因此，正确编写和运行微基准测试也很重要，但正确分析也很重要。

除了其他优秀的建议之外，我还要注意以下几点：
对于某些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实现。