破解迷雾:关于Java性能方面的9个谬论

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。如果你不得不写基准测试时，不要埋头苦干，你需要从他人那里汲取意见和经验。