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;
} #nally {
lock.unlock();
}
}
}
class SyncIncrementer implements Incrementer {
评论0
最新资源