关键点：

规则 0：正确表述问题以及您要检查的内容。

糟糕的任务：

我想检查哪个更快ArrayList或LinkedList？

更好的：

在我的应用程序中，插入最常发生在列表的中间。什么对我的任务更好ArrayList？LinkedList

更好的是：

在我的应用程序中，插入最常发生在列表的中间，而在阅读时，我通常需要一次查看一行中的多个元素。什么对我的任务更好ArrayList？LinkedList

规则 1：阅读各种 JVM 和微基准的权威文章。例如，Brian Goetz，2005 年。但不要指望测量会带来奇迹。所有基准测试都在上下文中测量一组有限的指标。

规则 2：始终包含一个 jvm 预热阶段，该阶段在实际测量阶段之前运行您的测试以进行完全初始化和编译。（以一种好的方式，您需要花费数万次迭代）。

规则 3：始终使用 flags 等运行-XX:+PrintCompilation，-verbose:gc以确保编译器和 jvm 的其他部分不会在采样阶段执行计划外操作。

规则 4：注意 -client 和 -server 之间的区别，以及 OSR（堆栈替换）和常规编译。首选服务器而不是客户端，常规编译优于 OSR。

规则 5：注意初始化效果。在测量阶段第一次不要向控制台打印任何内容，因为输出会初始化类。不要在热身阶段之外加载新类，除非您正在测试类加载本身。

规则 6：注意反优化和重新编译的影响。不允许在测量阶段第一次使用任何代码分支，因为编译器可能会基于更早的乐观假设重新编译代码，即根本不会使用此路径。规则 2是您抵御此类影响的第一道防线。

规则 7：使用正确的工具来阅读编译器的核心内容，并期望对生成的代码感到惊讶。在形成关于是什么减慢代码的理论之前，请先检查一下代码。

规则 8：减少测量中的噪音。在安静的机器上运行测试。运行几次，丢弃异常值。用于-Xbatch将编译器与应用程序序列化，并考虑设置它-XX:CICompilerCount=1以防止编译器与自身并行运行。

规则 9：使用现成的测量库。例如：JMH、Caliper或Bill 和 Paul 的优秀 UCSD Benchmarks for Java。

规则 10：如果你自己写，那么使用System.nanoTime()，因为 System.currentTimeMillis()可能有问题。在 Linux 系统上，当使用 NTP 守护程序时，两个序列号之间的差异System.currentTimeMillis()可能为负数。或者，您可以使用StopWatch来自相同Apache commons或Guava的类。

规则 11：System.gc()在测试之间调用会很有用（但不是在迭代之间！）。

有用的文章：

1. IBM 的动态编译和性能测量。
2. 关于IBM 的Java 性能监控你不知道的 5 件事。
3. 避免 JVM 上的基准测试陷阱。