[关闭]
@XingdingCAO 2017-12-13T14:00:55.000000Z 字数 4076 阅读 1793

Effective Java(第2版)：Item 5 —— Avoid creating unnecessary objects

Java constructor

实例的重用

通常情况下，对一个物体的重复利用是优于反复创建等效新物体的。重用利用不仅更快而且拥有更好的格式。

通过静态工厂方法(Item 1)来实现重用

——在Item 1中讨论过的静态工厂方法有一个特点——实例化可控，这样就可以返回相同实例的引用。而构造方法则必须在每次调用时生成新的实例。
——例如，Boolean类中的静态工厂方法valueOf(String)和构造方法Boolean(String)。前者返回了类中的静态常量。而后者必然构造了新的实例。

  1. public static boolean parseBoolean(String s) {
  2.     return ((s != null) && s.equalsIgnoreCase("true"));
  3. }
  1. public static final Boolean TRUE = new Boolean(true);
  2. public static final Boolean FALSE = new Boolean(false);
  3. public static Boolean valueOf(String s) {
  4.     return parseBoolean(s) ? TRUE : FALSE;
  5. }
  1. public Boolean(boolean value) {
  2.     this.value = value;
  3. }
  4. public Boolean(String s) {
  5.     this(parseBoolean(s));
  6. }

不变类的重用

如果一个类是不变的，那么它往往就是可重用的。下面，以对String类的重用为例来说明一下：

  1.     public final class String 
  2.     implements java.io.Serializable, Comparable<String>, CharSequence {
  3.         /** The value is used for character storage. */
  4.         private final char value[];
  6.         /** Cache the hash code for the string */
  7.         private int hash; // Default to 0
  9.         public String(String original) {
  10.             this.value = original.value;
  11.             this.hash = original.hash;
  12.         }
  14.         ...
  16.     }

1. 极端情况——完全不重用

  1.     //Disapproved
  2.     for (int i = 0; i < 10; i++) {
  3.         String str = new String("content");
  4.         ...
  5.     }

从String的源码可以看出，每次循环都会在程序运行时新建一个对相同字符数组的引用 和 相同的哈希码cache。这些循环中的初始化操作，无疑影响着性能的表现。

2.改进后——实现重用

  1.     String str = "content";
  2.     for (int i = 0; i < 10; i++) {
  3.             ...
  4.     }

改进后，不仅减少了重复初始化的性能损耗，而且String类的实例可以被在相同JVM上同时进行的其他程序共享，更加高效。

拓展阅读

关于String类的重用，和普通类相比实际上较为复杂，想要进一步了解可参考阅读这篇文章。

可变类的重用

当已知可变类的实例不会被更改时重用实例

就像不变类的重用一样，如果你已经事先知道了某个可变类的实例在运行时并不会变化，那么这个实例就可以被重用。例如，Date类(可变类)的实例在其值被确定后就不再改变，那么就非常适合拿来重用。仔细观察下面的例子，你会发现虽然并未出现循环，但是某个频繁使用的方法中的内部变量也亟需重用，来减少那些容易被忽略的性能损耗。

  1. public class Person{
  2.   private final Date birthDay;
  4.   //Other fields, methods and constructors omitted
  6.   //DON'T DO THIS
  7.   public boolean isBabyBoomer(){
  8.     //Umeccessary alloction of expensive object
  9.     Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
  10.     gmtCal.set(1946,Calendar.JANUARY,1,0,0,0);
  11.     Date boomStart = gmtCal.getTime();
  12.     gmtCal.set(1965,Calendar.JANUARY,1,0,0,0);
  13.     Date boomEnd = gmtCal.getTime();
  14.     return birthDate.compareTo(boomStart) >= 0 && birthDate.compareTo(boomEnd) < 0;
  15.   }
  16. }

如下，改进后的Person类，只初始化了Calendar TimeZone Date类的实例一次，而不是在方法被调用时反复初始化。这样改进后，性能的提升是非常明显的（一千万次执行的耗时从32000ms下降到了130ms）；而且将类的内部变量独立成为类的静态内部常量使逻辑更为清晰，可读性更强。

  1. public class Person {
  2.        private final Date birthDate;
  4.        // Other fields, methods, and constructor omitted
  6.        /**
  7.         * The starting and ending dates of the baby boom.
  8.         */
  9.        private static final Date BOOM_START;
  10.        private static final Date BOOM_END;
  12.        static {
  13.            Calendar gmtCal =
  14.                Calendar.getInstance(TimeZone.getTimeZone("GMT"));
  15.            gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
  16.            BOOM_START = gmtCal.getTime();
  17.            gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
  18.            BOOM_END = gmtCal.getTime();
  19.        }
  21.        public boolean isBabyBoomer() {
  22.            return birthDate.compareTo(BOOM_START) >= 0 &&
  23.                   birthDate.compareTo(BOOM_END)   <  0;
  24.        } 
  25. }

但是，上例的改进措施并不一定会获得巨大的性能提升，上例中的Calendar类的初始化十分耗时才导致了性能的巨大提升。

另外值得注意的一点就是，在Person类被使用时，BOOM_START BOOM_END字段的初始化为类的初始化带了额外的性能开销。为了减少额外的开销，可以将字段的加载延迟到实际使用时再进行，即：lazily initialize。实际的操作可以是将字段封闭在静态内部类中，然后再通过实现完全的延迟初始化。但是，为了实现完全的延迟初始化，不仅带来了复杂的实现结构，而且又会损耗性能，可能会丢掉已经获得的巨大性能提升，得不偿失。

保持敏锐的嗅觉

上面的例子很明显地需要提取重复的变量，从而实现重用，而还有一些情况并没有这么明显，需要编程人员保持敏锐的嗅觉。例如，适配器Adaptor设计模式（也被称为视图view设计模式）中我们就容易忽略其重用性。Adaptor是一个负责后台对象的、为后台对象提供可选接口的对象。一个Adaptor对象，除了它所代表的后台对象的状态，它本身是没有状态的。所以，创建多个Adaptor对象是没有必要的。

再比如，Map接口的keySet方法返回了一个包含了映射中所有键值的Set对象。看起来每次调用该方法，都会得到不同的Set对象。但实际上，对于一个给定的Map对象，多次调用该方法得到的是同一个Set实例。尽管Set实例是可变的，但是所有返回值却是一致的：一个返回的对象改变了，所有的返回对象都同时改变了，因为这个对象对应的是同一个Map对象。返回多个keySet视图对象(由Map产生，随它变化)是无害的，但也是没有必要的。

在Java 1.5中有了新的创建不必要对象的方式，叫做自动装(拆)箱(自动将原始类型装箱为包装类亦或反之)。自动装(拆)箱模糊了原始类型与包装类的界限，但并没有消除这个界限：还有一些细微的语义上的区别和不细微的性能上的差异。请看下面的程序，它将所有int类型的正数加了起来。为了不产生最高位的进位，程序使用了Long来保存结果。

  1. // Hideously slow program! Can you spot the object creation?
  2.    public static void main(String[] args) {
  3.        Long sum = 0L;
  4.        for (long i = 0; i < Integer.MAX_VALUE; i++) {
  5.            sum += i;
  6.    }
  7.        System.out.println(sum);
  8. }

程序给出了正确的答案，但是它远比它本来应该的速度慢。原因就在一个字母的错误。变量sum被声明为Long类型而非long类型，这就意味着这个程序创建了个Long的实例。原程序的运行时间达到了43秒，而将sum更改为long类型后缩短到了6.8秒。这就告诉我们偏爱原始类型而少用包装类，并且小心潜在的拆装箱操作。

总结

本篇文章告诉你的不是：创建实例是“昂贵”(耗费资源)的、应该避免的。相反，一些构造方法做了很少的事情，这些小的对象的创建与回收是“廉价”的，尤其在现代的JVM上。创建额外的对象去加强程序的明确性、简洁性或者通常是不错的选择。

维持你自己的对象池的对象构建是应该避免的，除非对象池中的对象都是重量级 (构建时非常耗费资源或时间)的。经典的案例就是数据库的连接（例如：Tomcat中DBCP2），构建对象的成本足够高以至于重用是合理的。此外，数据库还可能限制了连接数的上限。大体上来讲，维持你自己的对象池会使你的代码杂乱不堪，增加了内存印记，还影响着性能。现代JVM有着高度优化的垃圾回收机制，在与轻量级的对象池的比拼上可以轻松胜出。

添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注