代码优化最重要的作用应该是避免未知的错误,因此在写代码的时候,从源头开始注意各种细节,权衡并使用最优的选择,将会很大程度上避免出现未知的错误,从长远看也极大的降低了工作量。所以说,代码优化的目标是减小代码体积、提高代码运行效率。优化是无止境的,本文也只是给出了一些常见的优化建议。
带有final修饰符的类是不可派生的。在Java核心API中,有许多应用final的例子,例如java.lang.String,整个类都是final的。为类指定final修饰符可以让类不可以被继承,为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final,则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法,内联对于提升Java运行效率作用重大,具体可以查阅Java运行期优化相关资料,此举能够使性能平均提高50%。
特别是String对象的使用,出现字符串连接时应该使用StringBuilder/StringBuffer代替。由于Java虚拟机不仅要花时间生成对象,以后可能还需要花时间对这些对象进行垃圾回收和处理,因此生成过多的对象将会给程序的性能带来很大的影响。
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中,速度较快,其他变量,如静态变量、实例变量等,都在堆中创建,速度较慢。另外,栈中创建的变量,随着方法的运行结束,这些内容就没了,不需要额外的垃圾回收。
Java编程过程中,进行数据库连接、IO流操作时务必小心,在使用完毕后,及时关闭以释放资源。因此对这些大对象的操作会造成系统大的开销,稍有不慎,将会导致严重的后果。
//性能不好,list.size()会重复调用
for(int i = 0; i < list.size(); i++) {
...
}
//建议替换为如下:
for(int i = 0, length = list.size(); i < length; i++) {
...
}
//如上写法在list.size()很大的时候,就减少了很多的消耗。
这个原则其实就是节约,具体样例如下。
//不好的示范
String str = "aaa";
if(i == 1) {
list.add(str);
}
//建议替换为如下:
if(i == 1) {
String str = "aaa";
list.add(str);
}
异常对性能不利,抛出异常首先要创建一个新的对象,Throwable接口的构造函数调用名为filllnStackTrace()的本地同步方法,filllnStackTrace()方法检查堆栈,收集调用跟踪信息。只要有异常被抛出,Java虚拟机就必须调整调用堆栈,因为在处理过程中创建了一个新的对象。异常只要用于错误处理,不应该用来控制程序流程。
这个肯定大家没有疑问的,性能优化的实现而已。
用移位操作可以极大地提高性能,因为在计算机底层,对位的操作是最方便、最快的,但是移位操作虽然快, 可能会使代码不太好理解,因此更好加上相应的注释。
//不好的示范
for(val = 0; val < 100000; val += 5) {
a = val * 8;
b = val / 2;
}
//建议修改实现:
for(val = 0; val < 100000; val += 5) {
a = val << 3;
b = val >> 1;
}
//不好的示范
for(int i = 1; i <= count; i++) {
Object obj = new Object();
}
//上面这种做法会导致内存中有count份Object对象引用存在,
//count很大的话,就耗费内存了,建议为如下实现。
Object obj = null;
for(int i = 0; i <= count; i++) {
obj = new Object();
}
//如上实现内存中只有一份Object对象引用,
//每次new Object()的时候,Object对象引用指向不同的Object罢了,
//但是内存中只有一份,这样就大大节省了内存空间了。
因为这毫无意义,这样只是定义了引用为static final,数组的内容还是可以随意改变的,将数组声明为public更是一个安全漏洞,这意味着这个数组可以被外部类所改变。
使用单例可以减轻加载的负担、缩短加载的时间、提高加载的效率,但并不是所有地方都适用于单例,简单来说,单例主要适用于以下三个方面:
因为当某个对象被定义为static的变量所引用,那么gc通常是不会回收这个对象所占有的堆内存的。
public class A {
private static B b = new B();
}
//此时静态变量b的生命周期与A类相同,
//如果A类不被卸载,那么引用B指向的B对象会常驻内存,直到程序终止。
为了清楚不再活动的会话,许多应用服务器都有默认的会话超时时间,一般为30分钟。当应用服务器需要保存更多的会话时,如果内存不足,那么操作系统会把部分数据转移到磁盘,应用服务器也可能根据MRU(最近最频繁使用)算法把部分不活跃的会话转储到磁盘,甚至可能抛出内存不足的异常。如果会话要被转储到磁盘,那么必须要先被序列化,在大规模集群中,对对象进行序列号的代价是很昂贵的。因此,当会话不再需要时,应当及时调用HttpSession的invalidate()方式清楚会话。
这是JDK推荐给用户的,JDK API对于RandomAccess接口的解释是实现RandomAccess接口用来表明其支持快速随机访问,此接口的主要目的是允许一般的算法更改其行为,从而将其应用到随机或连续访问列表时能提供良好的性能。实际经验表明,实现RandomAccess接口的类实例,假如是随机访问的,使用普通for循环效率将高于使用foreach循环,反过来,如果是顺序访问的,则使用Iterator会效率更高。
//样板代码:可以使用类似如下的代码作判断
if(list instanceof RandomAccess) {
for(int i = 0; i < list.size(); i++) {}
} else {
Iterator> iterator = list.iterable();
while(iterator.hasNext()) {iterator.next()}
}
尽量使用同步代码块,避免对那些不需要进行同步的代码也进行了同步,影响了代码执行效率。
这样在编译期间就可以把这些内容放入常量池中,避免运行期间计算生成常量的值。另外,将常量的名字以大写命令也可以方便区分出常量与变量。
这毫无意义,如果代码中出现"The value of the lical variable i is not used"、“The import java.util is never used”,那么请删除这些无用的内容,虽说没啥影响,但是有些时候编译期会报错,譬如没import用到的类被删掉了。
不建议在程序运行过程中使用,除非万不得已,尤其是频繁使用反射机制,特别是Method的invoke方法,如果确实有必要,一种建议性的做法是将那些需要通过反射加载的类在项目启动的时候通过反射实例化出一个对象并放入内存,用户只关心和对端交互的时候获取最快的响应速度,并不关心对端的项目启动花多久时间。
这两个池都是用于重用对象的,前者可以避免频繁的打开和关闭连接,后者可以避免频繁的创建和销毁线程。
带缓冲的输入输出流,即BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream,这可以极大地提升IO效率。
public方法即对外提供的方法,如果给这些方法太多形参的话主要坏处是违反了面向对象的编程思想,Java讲求一切都是对象,太多的形参和面向对象的编程思想并不契合,参数太多势必导致方法调用的出错概率增加。
因为有可能 == 会误写成 =,而在 C/C++ 中 if (i = 1) 是会出问题的,而 Java 会在编译时报错 “Type mismatch: cannot convert from int to boolean”,但是,尽管Java的 if (i == 1) 和 if (1 == i) 在语义上没有任何区别,从阅读习惯上讲,建议使用前者会更好些。
本意是想打印出数组内容,却打出来的是对象信息,甚至有可能因为数组引用为空而导致空指针异常。对于集合toString()是可以打印出集合里面的内容的,因为集合的父类AbstractCollections重写了Object的toString()方法。
这很明确,譬如long转int是会存在潜在风险的。
如果一个集合类是公用的(也就是说不是方法里面的属性),那么这个集合里面的元素是不会自动释放的,因为始终有引用指向它们。所有,如果公用集合里面的某些数据不使用而不去remove掉它们,那么将会造成这个公用集合不断增大,使得系统有内存泄漏的隐患。
因为String.valueOf()方法底层调用了Integer.toString()方法,但是会在调用前做空判断;Integer.toString()是直接调用了;i+""底层使用StringBuilder实现,先用append方法拼接,再用toString()方法获取字符串。
遍历Map的方式有很多,通常场景下我们需要的是遍历Map中的Key和Value,那么推荐使用的、效率最高的方式是entrySet(),如果只是想遍历一下这个Map的key值则keySet()会比较合适一些。
虽然有些麻烦,却能避免资源泄漏,这其实和try-catch机制相关,各自分开close各自的try-catch就会互不影响,防止写在一个try-catch中因为一个异常了后面的释放不了。
因为线程池技术做的是一个线程重用,这意味着代码运行过程中一条线程使用完毕并不会被销毁而是等待下一次的使用,而Thread类中持有ThreadLocal.ThreadLocalMap的引用,线程不销毁意味着上条线程set的ThreadLocal.ThreadLocalMap中的数据依然存在,那么在下一条线程重用这个Thread的时候很可能get到的是上条线程set的数据而不是自己想要的内容。这个问题非常隐晦,一旦出现这个原因导致的错误,没有相关经验或者没有扎实的基础非常难发现这个问题,因此在写代码的时候就要注意这一点,这将给你后续减少很多的工作量。
这么做可以清楚地知道这个方法由父类继承而来,同时可以保证重写成功,此外在抽象类中对方法签名进行修改,实现类会马上报出编译错误。
因为每次虚拟机碰到"+"这个操作符对字符串进行拼接地时候会new出一个StringBuilder,然后调用append方法,最后调用toString()方法转换字符串赋值给对象,所以循环多少次,就会new出多少个StringBuileder()来,这对于内存是一种浪费。
异常处理效率低,RuntimeException的运行时异常中绝大多数完全可以由程序员来规避,比如ArithmeticException可以通过判断除数是否为空来规避,NullPointerException可以通过判断对象是否为空来规避,IndexOutOfBoundsException可以通过判断数组/字符串长度来规避,ClassCastException可以通过instanceof关键字来规避,ConcurrentModificationException可以使用迭代器来规避
这是因为静态类、单例类、工厂类这种类本来我们就不需要外部将它们new出来,将构造函数置为private之后,保证了这些类不会产生实例对象。
总结:代码优化就像是鲨鱼吃虾米,可能吃一只两只和没吃没有什么区别,但是吃一万只十万只有可能就吃饱了。所以可能一个小的优化对效率并不会带来多大的提升,但是积少成多,这世间万物,哪一件事情不是积少成多,逐渐成熟,一口吃不了大胖子,所有的成功,都是基于一点一滴的努力。