Java理论和实践: 一个有缺陷的微基准的剖析 - 编程入门网
Java理论和实践: 一个有缺陷的微基准的剖析时间:2011-02-04 IBM Brian Goetz即使性能不是当前项目的一个关键需求,甚至没有被标明为一个需求,通常也难于忽略性能问题,因为您可能会认为忽略性能问题将使自己成为“差劲的工程师”。开发人员在以编写高性能代码为目标的时候,常常会编写小的基准程序来度量一种方法相对于另一种方法的性能。不幸的是,正如您在 December 撰写的 "动态编译与性能测量" 这期文章中所看到的,与其他静态编译的语言相比,评论用 Java 语言编写的给定惯用法(idiom)或结构体的性能要困难得多。 一个有缺陷的微基准 在我发表了十月份的文章 "JDK 5.0 中更灵活、更具可伸缩性的锁定机制" 之后,一个同事给我发了 SyncLockTest 基准(如清单 1 所示),据说用它可以判断 synchronized 与新的 ReentrantLock 类哪一个“更快”。他在自己的手提电脑上运行了该基准之后,作出了与那篇文章不同的结论,说同步要更快些,并且给出了他的基准作为“证据”。整个过程 —— 微基准的设计、实现、执行和对结果的解释 —— 在很多方面都存在缺陷。其实我这个同事是个很聪明的家伙,并且对这个基准也花了不少功夫,可见这种事有多难。 清单 1. 有缺陷的 SyncLockTest 微基准
SyncLockTest 定义了一个接口的两种实现,并使用 System.nanoTime() 来计算每种实现运行 10,000,000 次的时间。在保证线程安全的情况下,每种实现增加一个计数器;其中一种实现使用内建的同步,而另一种实现则使用新的 ReentrantLock 类。此举的目的是回答以下问题:“哪一个更快,同步还是 ReentrantLock?”让我们看看为什么这个表面上没有问题的基准最终没能成功地度量出想要度量的东西,甚至没有度量出任何有用的东西。 Java理论和实践: 一个有缺陷的微基准的剖析(2)时间:2011-02-04 IBM Brian Goetz构想上的缺陷 暂时先不谈实现上的缺陷, SyncLockTest 首先从构想上就存在缺陷 —— 它误解了它要回答的问题。这个基准的目的是要度量同步和 ReentrantLock 的性能代价,它们是用于协调多个线程的行为的不同技术。然而,该测试程序只包含一个线程,因而显然不存在竞争。它没有首先测试那些真正与锁相关的场景! 在早期的 JVM 实现中,无竞争的同步比较慢,这是众所周知的。然而,从 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |