关于Java性能的9个谬论

发表于:2013-05-14来源:InfoQ作者:Ben Evans点击数: 标签:性能
关于Java性能的9个谬论? Java的性能有某种黑魔法之称。部分原因在于Java平台非常复杂,很多情况下问题难以定位。然而在历史上还有一种趋势,人们靠智慧和经验来研究Java性能,而不是靠应用统计和实证推理。在这篇文章中,我希望拆穿一些最荒谬的技术神话。

  Java性能有某种黑魔法之称。部分原因在于Java平台非常复杂,很多情况下问题难以定位。然而在历史上还有一种趋势,人们靠智慧和经验来研究Java性能,而不是靠应用统计和实证推理。在这篇文章中,我希望拆穿一些最荒谬的技术神话。

  1.Java很慢

  关于Java的性能有很多谬论,这一条是最过时的,可能也是最为明显的。

  确实,在上世纪90年代和本世纪初处,Java有时是很慢。

  相关厂商内容

  JavaOne 2013再次回归,7月22-25日上海世博中心,精彩继续,5月31日前购票享半价!

  2013年Esri空间信息技术开发者大会

  GIS系列白皮书下载:云GIS平台介绍——ArcGIS Online

  还记得Delphi么?Embarcadero携ER/Studio、RAD Studio XE和HTML5 Builder重装上阵

  百度技术沙龙第三十八期:个性化推荐(2013年5月25日 周六)

  然而从那以后,虚拟机和JIT技术已经有了十多年的改进,Java的整体性能现在已经非常好了。

  在6个独立的Web性能基准测试中,Java框架在24项测试中有22项位列前四。

  尽管JVM利用性能剖析仅优化常用的代码路径,但这种优化效果很明显。很多情况下,JIT编译的Java代码和C++一样快,而且这样的情况越来越多了。

  尽管如此,依然有人认为Java平台很慢,这或许源自体验过Java平台早期版本的人的历史偏见。

  在下结论之前,我们建议保持客观的态度,并且评估一下最新的性能结果。

  2.可以孤立地看待单行Java代码

  考虑下面这行短小的代码:

  MyObject obj = new MyObject();

  对Java开发者而言,看似很明显,这行代码一定会分配一个对象并调用适当的构造器。

  我们也许可以据此推出性能边界了。我们认为这行代码一定会导致执行一定量的工作,基于这种推定,就可以尝试计算其性能影响了。

  其实这种认识是错误的,它让我们先入为主地认为,不管什么工作,在任何情况下都会进行。

  事实上,javac和JIT编译器都能够将死代码优化掉。就JIT编译器而言,基于性能剖析数据,甚至可以通过预测将代码优化掉。在这样的情况下,这行代码根本不会运行,所以不会影响性能。

  此外,在某些JVM中——比如JRockit——JIT编译器甚至可以将对象上的操作分解,这样即便代码路径还有效,分配操作也可以避免。

  这里的寓意是,在处理Java性能问题时,上下文非常重要,过早的优化有可能产生违反直觉的结果。所以最好不好过早优化。相反,应该总是构建代码,并且使用性能调校技术来定位性能热点,然后加以改进。

  3.微基准测试和你想象的一样

  正如我们上面看到的那样,检查一小段代码不如分析应用的整体性能来的准确。

  尽管如此,开发者还是喜欢编写微基准测试。似乎对平台底层的某些方面进行修修补补会带来无穷的乐趣。

  理查德·费曼曾经说过:“不要欺骗自己,你自己正是最容易被欺骗的人。”这句话用来说明编写Java微基准测试这件事是再合适不过了。

  编写良好的微基准测试极其困难。Java平台非常复杂,而且很多微基准测试只能用于测量瞬时效应,或是Java平台的其他意想不到的方面。

  例如,如果没有经验,编写的微基准测试往往就是测一下时间或垃圾收集,却没有抓住真正的影响因素。

  只有那些有实际需求的开发者和开发团队才应该编写微基准测试。这些基准测试应该完全公开(包括源代码),而且是可以复现的,还应接受同行评审及进一步的审查。

  Java平台的很多优化表明统计运行和单次运行对结果影响很大。要得到真实可靠的答案,应该将一个单独的基准测试运行多次,然后把结果汇总到一起。

  如果读者感觉有必要编写微基准测试,Georges、Buytaert和Eeckhout等人的论文《利用严格的统计方法评测Java 性能(Statistically Rigorous Java Performance Evaluation)》是个不错的开始。缺乏适当的统计分析,我们很容易被误导。

  有很多开发好的工具以及围绕这些工具的社区(比如Google的Caliper)。如果确实有必要编写微基准测试,那也不要自己编写,这时需要的是同行的意见和经验。

  4.算法慢是性能问题的最常见原因

  在开发者之间有一个很常见的认知错误(普通大众也是如此),即认为系统中他们控制的那部分很重要。

  在探讨Java性能时,这种认知错误也有所体现:Java开发者认为算法的质量是性能问题的主要原因。开发者考虑的是代码,因此他们自然会偏向于考虑自己的算法。

  实际上在处理一系列现实中的性能问题时,人们发现算法设计是根本问题的几率不足10%。

  相反,与算法相比,垃圾收集、数据库访问和配置错误导致应用程序缓慢的可能性更大。

  大部分应用处理的数据量相对较小,因此,即使主要算法效率不高,通常也不会导致严重的性能问题。可以肯定,我们的算法不是最优的;尽管如此,算法带来的性能问题还是算小的,更多性能问题是应用栈的其他部分导致的。

  因此我们的最佳建议是,使用实际生产数据来揭开性能问题的真正原因。要测量性能数据,而不是凭空猜测!

  5.缓存可以解决所有问题

  “计算机科学中的所有问题都可以通过引入一个中间层来解决。”

  David Wheeler的这句程序员格言(在互联网上,这句话至少还被认为是其他两位计算机科学家说的)非常常见,尤其是在Web开发者之中很流行。

  如果未能透彻理解现有的架构,而且分析也已停顿,往往就是“缓存可以解决所有问题”这种谬论抬头的时候了。

  在开发者看来,与其处理吓人的现有系统,还不如在前面加一层缓存,将现有系统隐藏起来,以此期待最好的情况。无疑,这种方式只是让整体架构更复杂了,当下一个接手的开发者打算了解系统现状时,情况会更糟糕。

  规模庞大、设计拙劣的系统往往缺乏整体的设计,是一次一行代码、一个子系统这样写出来的。然而很多情况下,简化并重构架构会带来更好的性能,而且几乎总是更容易让人理解。

原文转自:http://www.infoq.com/cn/articles/9_Fallacies_Java_Performance

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)