即使性能不是当前项目的一个关键需求，甚至没有被标明为一个需求，通常也难于忽略性能问题，因为您可能会认为忽略性能问题将使自己成为“差劲的工程师”。开发人员在以编写高性能代码为目标的时候，常常会编写小的基准程序来度量一种方法相对于另一种方法的性能。不幸的是，正如您在 December 撰写的 "动态编译与性能测量" 这期文章中所看到的，与其他静态编译的语言相比，评论用 Java 语言编写的给定惯用法（idiom）或结构体的性能要困难得多。
一个有缺陷的微基准
在我发表了十月份的文章 "JDK 5.0 中更灵活、更具可伸缩性的锁定机制" 之后，一个同事给我发了 SyncLockTest 基准（如清单 1 所示），据说用它可以判断 synchronized 与新的 ReentrantLock 类哪一个“更快”。他在自己的手提电脑上运行了该基准之后，作出了与那篇文章不同的结论，说同步要更快些，并且给出了他的基准作为“证据”。整个过程 —— 微基准的设计、实现、执行和对结果的解释 —— 在很多方面都存在缺陷。其实我这个同事是个很聪明的家伙，并且对这个基准也花了不少功夫，可见这种事有多难。
清单 1. 有缺陷的 SyncLockTest 微基准
interface Incrementer {
void increment();
}
class LockIncrementer implements Incrementer {
private long counter = 0;
private Lock lock = new ReentrantLock();
public void increment() {
lock.lock();
try {
++counter;
} finally {
lock.unlock();
}
}
}
class SyncIncrementer implements Incrementer {
private long counter = 0;
public synchronized void increment() {
++counter;
}
}
class SyncLockTest {
static long test(Incrementer incr) {
long start = System.nanoTime();
for(long i = 0; i < 10000000L; i++)
incr.increment();
return System.nanoTime() - start;
}
public static void main(String[] args) {
long synchTime = test(new SyncIncrementer());
long lockTime = test(new LockIncrementer());
System.out.printf("synchronized: %1$10d\n", synchTime);
System.out.printf("Lock: %1$10d\n", lockTime);
System.out.printf("Lock/synchronized = %1$.3f",
(double)lockTime/(double)synchTime);
}
}
SyncLockTest 定义了一个接口的两种实现，并使用 System.nanoTime() 来计算每种实现运行 10,000,000 次的时间。在保证线程安全的情况下，每种实现增加一个计数器；其中一种实现使用内建的同步，而另一种实现则使用新的 ReentrantLock 类。此举的目的是回答以下问题：“哪一个更快，同步还是 ReentrantLock？”让我们看看为什么这个表面上没有问题的基准最终没能成功地度量出想要度量的东西，甚至没有度量出任何有用的东西。