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 ]
[
下一页 ]