Java理论和实践：一个有缺陷的微基准的剖析.docVIP

Java 理论和实践: 一个有缺陷的微基准的剖析 还有其他类型吗？ 众所周知，软件工程师常常受到性能问题的困扰，有时候甚至很过分。虽然有时候性能在一个软件项目中是最重要的需求，例如在为高速交换机开发协议路由软件时便是如此，但在大多数情况下，需要在性能需求与其他需求之间进行平衡，例如功能性、可靠性、可维护性、可扩展性、投入市场的时间以及其他业务和工程上的考虑。在本月的 Java 理论和实践 中，专栏作家 Brian Goetz 将探讨为什么度量 Java 语言结构体的性能比看上去要难得多。请在本文附带的 讨论论坛 中与作者和其他读者交流您对本文的看法。（也可以通过单击文章顶部或底部的 讨论 来访问该论坛。） 即使性能不是当前项目的一个关键需求，甚至没有被标明为一个需求，通常也难于忽略性能问题，因为您可能会认为忽略性能问题将使自己成为“差劲的工程师”。开发人员在以编写高性能代码为目标的时候，常常会编写小的基准程序来度量一种方法相对于另一种方法的性能。不幸的是，正如您在 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 ; 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？”让我们看看为什么这个