避免创建不必要的对象
一般来说,如果对象是不可变的,最好重用一个对象,而不是每次需要的时候,就去重新一个相同功能的对象,重用可以提高性能。
作为一个反面例子,看看下面的语句:
String s = new String("java");//类似于包装类,基础数据装箱
每次执行以上代码的时候,都会重新创建一个新的String实例,但是创建的实例功能和意义完全是不必要的,String构造器的参数(“java”)本身就是一个String实例,功能方面等同于构造器所创建的对象,如果以上代码是在一个循环体内,或者在一个被频繁调用的方法中,就会出现成千上万个不必要的实例。
改进后的代码如下:
String s = "java";//基础数据类型被丢到常量池了
这个版本的代码只用了一个实例,而不是每次调用时就创建一个新的实例,而且,它可以保证,对于所有在同一台虚拟机上运行的代码,只要包含相同的字符串字面常量,该对象就会被重用。
对于同时提供了静态工厂方法和构造器的不可变类,优先使用静态工厂方法,而不是构造器,以避免创建不必要的对象。例如:Boolean b = Boolean.valueOf(true);总是应该优先于Boolean b = new Boolean(true);
有些对象创建的代价比其他对象高得多,如果重复的需要这个’‘昂贵的类’,建议将它缓存起来,但是,在实际情况中,在创建这种类的时候,并非总是那么显而易见,下面介绍一种最容易的方法,使用一个正则表达式来验证是否为一个有效的邮箱:
public static boolean validationEmail(String email){
return email.matches("^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$");
}
这个实现的问题它依赖于String.matches();方法,虽然String.matches()方法最易于查看一个字符串是否与正则表达式相匹配,但并不适合在注重性能的形况下重复使用,它在内部为正则表达式创建了一个Pattern实例:
// String.matches();方法源代码
public static boolean matches(String regex, CharSequence input) {
Pattern p = Pattern.compile(regex);
Matcher m = p.matcher(input);
return m.matches();
}
public static Pattern compile(String regex) {
return new Pattern(regex, 0);
}
但是每次调用,却只使用一次,之后就进行垃圾回收了,创建Pattern实例的代价很高,因为需要将正则表达式编译成一个有限状态机。
为了提升性能,应该显示的将正则表达式编译成一个Pattern不可变的实例,让它成为类初始化的一部分,并将它缓存起来,当每次调用validationEmail方法进行验证的时候,就会重用同一个实例:
private static final Pattern VALIDATION_RMAIL = Pattern.compile("^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$");
public static boolean validationEmail(String email){
return VALIDATION_RMAIL.matcher(email).matches();
}
例如,Map接口的keySet方法返回该Map对象的Set视图,其中包含该Map中所有的键(key),看是好像每次调用keySet方法都应该生成一个新的set实例,但是,对于一个给定的Map对象,实际上每次调用keySet方法返回的都是相同的set实例,虽然被返回的set实例可以被修改,但是所有返回的对象在功能上是等同,当其中一个对象发生变化,所有其他的返回对象也会发生变化,因为它们是由同一个Map支撑的, 虽然创建keySet视图对象的多个实例并无害处,却是不必要的,也没有好处。
// Map keySet() 方法源代码
public Set<K> keySet() {
Set<K> ks = keySet;
if (ks == null) {
ks = new KeySet();
keySet = ks;
}
return ks;
}
另一种创建多于对象的方法,称为自动装箱,它允许程序员将基本类型和装箱类型混用,按需要自动装箱和拆箱,自动装箱使得基本类型和装箱类型之间的差别变得模糊,但是并没有完全消除,它们在语义上还有微妙的差别,在性能也有着比较明显的差别,下面这个程序计算所有int正整数的总和,为此,必须使用long,因为int不够到,无法容纳所有int正整数值的总和。
private static long sum(){
Long sum = 0L;
for(long x = 0;x <= Integer.MAX_VALUE; x++){
sum += x;
}
return sum;
}
这段程序算出的答案是正确的,但是运行速度要慢些,因为将变量sum声明成了Long而不是long,意味着程序构造了大约2^31个多余的Long实例(大约每次往Long sum中增加long x时就构造一个实例),将sum声明从Long改为long,可以使运行时间从6.3秒减少了0.59秒。结论很明显,要优先使用基本类型而不是装箱类型,也要当心无意间的自动装箱。
当然,也不要错误的认为创建对象的代价非常昂贵,而尽可能的避免创建对象。相反,由于小对象的构造器只做了很少的显示工作,所以小对象的创建和回收是非常廉价的,特别是在现代的JVM实现上更是如此,通过创建附加的对象,提升程序的清晰性,简洁性和功能性,这通常是好事。
反之,通过维护自己的对象池来避免创建对象并不是一种好的做法,除非池中的对象都是非常重量级的,正确使用对象吃的典型示列就是数据量连接池,建立数据库连接的代价非常昂贵,因此重用这些对象非常有意义。而且,数据库的许可限制只能使用一定数量的连接对象。但是,一般而言,维护自己的对象池必定会把代码弄得很乱,
同时增加内存占用,并且还会损害性能,现代JVM实现具有高度优化的垃圾回收器,其性能很容易就超过了轻量级的对象池的性能。
注意:在提倡使用保护性的拷贝的时候,重用对象付出的代价要远远大于创建重复对象所付出的代价,必要时如果没有实施保护性拷贝,将会导致潜在的安全漏洞和Bug,而创建重复对象只会影响程序的风格和性能。
参考文章:https://www.jianshu.com/p/f5e40a401830