1700451969
1700451970
如果在ArrayList中存储了大量的数据，使用indexOf查找元素会比java.utils.Collections.binarySearch的效率低很多，原因是binarySearch是二分搜索法，而indexOf使用的是逐个元素比对的方法。这里要注意：使用binarySearch搜索时，元素必须进行排序，否则准确性就不可靠了。
1700451971
1700451972
（6）覆写Exception的fillInStackTrace方法
1700451973
1700451974
我们在第8章中提到fillInStackTrace方法是用来记录异常时的栈信息的，这是非常耗时的动作，如果我们在开发时不需要关注栈信息，则可以覆盖之，如下覆盖fillInStackTrace的自定义异常会使性能提升10倍以上：
1700451975
1700451976
class MyException extends Exception{
1700451977
1700451978
public Throwable fillInStackTrace（）{
1700451979
1700451980
return this；
1700451981
1700451982
}
1700451983
1700451984
}
1700451985
1700451986
（7）不建立冗余对象
1700451987
1700451988
不需要建立的对象就不能建立，说起来很容易，要完全遵循此规则难度就很大了，我们经常就会无意地创建冗余对象，例如这样一段代码：
1700451989
1700451990
public void doSomething（）{
1700451991
1700451992
//异常信息
1700451993
1700451994
String exceptionMsg=“我出现异常了，快来就救我！”；
1700451995
1700451996
try{
1700451997
1700451998
Thread.sleep（10）；
1700451999
1700452000
}catch（Exception e）{
1700452001
1700452002
//转换为自定义运行期异常
1700452003
1700452004
throw new MyException（e, exceptionMsg）；
1700452005
1700452006
}
1700452007
1700452008
}
1700452009
1700452010
注意看变量exceptionMsg，这个字符串变量在什么时候会被用到？只有在抛出异常时它才有用武之地，那它是什么时候创建的呢？只要该方法被调用就创建，不管会不会抛出异常。我们知道异常不是我们的主逻辑，不是我们代码必须或经常要到达的区域，那为了这个不经常出现的场景就每次都多定义一个字符串变量，合适吗？而且还要占用更多的内存！所以，在catch块中定义exceptionMsg方法才是正道：需要的时候才创建对象。
1700452011
1700452012
我们知道运行一段程序需要三种资源：CPU、内存、I/O，提升CPU的处理速度可以加快代码的执行速度，直接表现就是返回时间缩短了，效率提高了；内存是Java程序必须考虑的问题，在32位的机器上，一个JVM最多只能使用2GB的内存，而且程序占用的内存越大，寻址效率也就越低，这也是影响效率的一个因素。I/O是程序展示和存储数据的主要通道，如果它很缓慢就会影响正常的显示效果。所以我们在编码时需要从这三个方面入手接口（当然了，任何程序优化都是从这三方面入手的）。
1700452013
1700452014
Java的基本优化方法非常多，这里不再罗列，相信读者也有自己的小本本，上面所罗列的性能优化方法可能远比这里多，但是随着Java的不断升级，很多看似很正确的优化策略就逐渐过时了（或者说已经失效了），这一点还需要读者注意。最基本的优化方法就是自我验证，找出最佳的优化途径，提高系统性能，不可盲目信任。
1700452015
1700452016
1700452017
1700452018
[
上一页 ]
[ :1.700451969e+09 ]
[
下一页 ]