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为基准测试更切合这个的例子了。