关于Java性能方面的9个谬论.docVIP

关于Java性能方面的9个谬论 /it/JAVA/454.html Java性能问题被冠以某种黑暗魔法的称谓。一部分是因为其平台的复杂性，在很多情况下，无法定位其性能问题根源。然而，在以前对于 Java性能的技巧，有一种趋向：认为其由人们的智慧，经验构成，而不是应用统计和实证推理。在这篇文章中，我希望去验证一些最荒谬的技术神话。 1. Java运行慢 在所有最过时的Java性能谬论当中，这可能是最明显的言论。 是的，在90年代和20年代初期，Java确实有点慢。 然而，在那之后，我们有超过10年的时间来改进虚拟机和JIT技术，现在Java整个体系的性能已经快的令人惊讶。 在6个单独的web性能测试基准中，Java框架占据了24个当中的22个前四的位置。 JVM性能分析组件的使用不仅优化了通用的代码路径，而且在优化那些严重领域也很有成效。JIT编译代码的速度在大多数情况下跟C++一样快了。 尽管这样，关于Java运行慢的言论还是存在，估计是由于历史原因造成的偏见，这个偏见来自当时那些使用Java早期版本的人们。 我们建议，在匆忙下结论之前先保留意见和评估一下必威体育精装版的性能结果。 2. 单行java代码意味着任何事都是孤立的 考虑以下一小段代码： MyObject obj = new MyObject(); 对一个Java开发者而言，很明显能看出这行代码需要分配一个对象和运行一个对应的构造方法。 从这来看，我们可以开始推出性能边界。我们知道有一些精确数量的工作必须继续，因此基于我们的推测，我们可以计算出性能影响。 这儿有个认知偏见，那就是根据以往的经验，任何工作都需要被做。 实际上，javac和JIT编译器都可以优化无效代码。就拿JIT编译器来说，代码甚至可以基于数据分析而被优化掉，在这种情况下，该行代码将不会被运行，因此它就不会有什么性能方面的影响。 而且，在一些Java虚拟机(JVM)中，例如JRockit中,即使代码路径没有完全失效，JIT编译器为了避免分配对象甚至可以执行分解对象操作。 这段文字在这里的意义就是当处理Java性能方面的问题时，上下文很重要。而且过早的优化可能会产生意料之外的结果。所以为了获得最好的结果，不要试图过早的优化。与其不断构建你的代码不如用性能调整技术去定位并且改正代码性能的潜在危险区。 3. 一个微基准测试意味着你认为它是什么 正如以上看到的，推理一小段程序比分析应用程序的整体性能更不准确。尽管如此，开发者还是喜欢写为基准测试。有些人似乎从摆弄平台的某些低层次方面获取无穷无尽的内心快感。 理查德·费曼曾说：“第一个原则是,不要欺骗自己，而且自己是最容易被骗的人”。没有比编写Java为基准测试更切合这个的例子了。 写好微基准测试是极其困难的。Java平台很复杂，而且很多微基准测试只对测量瞬态效应或平台的其他意外方面有效。 例如，一个想当然的微基准测试频繁地在测量子系统时间或垃圾回收，而不是在试图捕捉效果时结束。 只有当开发者和团队有真正基准需求的时候才需要写微基准测试。这些基准测试应该打包到项目（包括源代码）随项目一起发布，并且这些基准测试应该是可重现的并可提供给他人审阅和进一步的审查。 Java平台的许多优化结果都指的是只运行单一基准测试用例时所得到的统计结果。一个单独的基准测试必须要多次运行才能得到一个比较趋近于真实答案的结果。 如果你认为到了必须要写微基准测试的时候，首先请读一下Georges, Buytaert, Eeckhout所著的”Statistically Rigorous Java Performance Evaluation”。如果没有统计学的知识，你会很容易误入歧途的。 网上有很多好的工具和社区来帮助你进行基准测试，例如Google的Caliper。如果你不得不写基准测试时，不要埋头苦干，你需要从他人那里汲取意见和经验。 4.算法慢是性能问题的最普遍原因 在程序员（和普通大众）中普遍存在一个错误观点就是他们总是理所当然地认为自己所负责的那部分系统才是最重要的。 就Java性能这个问题来说，Java开发者认为算法的质量是性能问题的主要原因。开发者会考虑如何编码，因此他们本性上就会潜意识地去考虑算法。 实际上，当处理现实中的性能问题时，算法设计占用了解决基本问题不到10%的时间。 相反，相对于算法，垃圾回收，数据库访问和配置错误会更可能造成程序缓慢。 大多数应用程序处理相对少量的数据，因此即使主算法有缺陷也不会导致严重的性能问题。因此，我们得承认算法对于性能问题来说是次要的;因为算法带来的低效相对于其他部分造成的影响来说是相对较小的，大多的性能问题来自于应用程序栈的其他部分。 因此我们的最佳建议就是依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。 缓存能解