在深入了解Java虚拟机里读到:
在try{}块里面执行代码,比if(x!=null)效率要高,前提是被catch的几率很低的情况下.
但是
在Effective Java里读到:
因为异常机制的设计初衷是用于不正常的情形,所以很少会有JVM实现视图对他们进行优化,使得与显示的测试一样快速.
把代码放在try-catch块中反而阻止了现代JVM实现本来可能要执行的某些特定优化.
对数组进行遍历的标准模式并不会导致冗余的检查.有些现代的JVM实现会将他们优化掉.
实际上在现代的JVM实现上,给予异常的模式比标准模式要慢得多.
在Java平台上对优化的结果进行测量,比在其他的传统平台上更有必要,因为Java程序设计语言没有很强的性能模型(Performance model).各种基本操作的相对开销也没有明确定义.程序员所编写的代码与CPU执行的代码之间存在"语义沟(semantic gap)",而且这条语义沟比传统的编译语言中的更大,这使得想可靠地预测出任何优化的性能结果都非常困难.大量流传的关于性能的说法最终都被证明为半真半假,或者根本就不正确.
不仅Java的性能模型未得到很好的定义,而且在不同的JVM实现,或者不同的发行版,以及不同的处理器,在它们这些当中也都各不相同.如果将要在多个JVM实现和多种硬件平台上运行程序,很重要的一点是,需要在每个Java实现上测量优化结果.有时候,还必须从不同的JVM实现或者硬件平台上得到性能结果之中进行权衡.
原则一:不要进行优化.
原则二(对于专家):还是不要进行优化