Effective Java 3rd 条目6 避免创建不必要的对象

这通常是恰当的：重用单个对象，而不是每次需要的时候创建一个新的功能相同的对象。重用既更快又更有风格。如果不可变，一个对象总是可以被重用(条目17)。

作为不应该做的事情的一个极端例子，考虑这个语句：

String s = new String("bikini");// 不要这么做！

每次执行时这个语句时创建一个新的String实例，这些对象创建没有一个是必要的。String构造子的参数(“bikini”)自身是一个String实例，在功能上和由构造子创建的所有对象是相同的。如果这个用法在一个循环里面或者在一个经常被调用的方法里面，那么可能不必要地创建了上百万的String实例。
改进版本仅仅如下：

String s = "bikini";

这个版本使用单个String实例，而不是每次执行时创建一个新的对象。此外，这也保证了这个对象被运行在同一个虚拟机中的其他代码重用，这些代码恰好有相同的字符串字面量[JLS, 3.10.5]。

通常，你可以优先用静态工厂方法(static factory method)(条目1)避免创建不必要的对象，而不是提供两者的不可变类的构造子。比如，Boolean.valueOf(String)方法比构造子Boolean(String)更可取，这个构造子在Java 9中被弃用了。构造子必须 每次被调用时创建一个新的对象，而在实践上工厂方法从来没有要求这么做，也不应该这么做。除了重用不变对象，如果你知道可变对象不会被改变，你也可以重用它们。

一些对象创建比其他的更加昂贵。如果你反复地需要这样的“昂贵对象”，为了重用而缓存是更加明智的。不幸的是，当你创建这样的对象，不总是明显的。假设你想编写一个方法，决定一个字符串是否是一个有效的罗马数字。这里是用正则表达式这种最容易的方式来做这件事：

// 性能可以大大的提高
static boolean isRomanNumeral(String s) { 
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" 
        + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$"); 
}

这个实现的问题在于，它依赖于String.matches方法。虽然String.matches是最容易的方式检测一个字符串是否符合正则表达式，在一个性能要求严格的情形中重复使用，是不适合的。这个问题是，它内部为正则表达式创建了一个Pattern实例，而且仅仅使用一次，在这之后，它符合垃圾回收的条件了。创建一个Pattern实例是相当昂贵的，因为他需要把正则表达式编译成一个受限的状态机。

为了提高性能，把正则表达式显示地编译成一个Pattern实例(是不可变的)，并作为类初始化的一部分，缓存它，然后对于每个isRomanNumeral方法的调用，重用同一个实例：

// 为了性能，重用昂贵的对象
public class RomanNumerals {
    private static final Pattern ROMAN = Pattern.compile( 
        "^(?=.)M*(C[MD]|D?C{0,3})" 
        + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

    static boolean isRomanNumeral(String s) { 
        return ROMAN.matcher(s).matches(); 
    }
}

isRomanNumeral的改进版，如果经常调用，会有显著的性能改进。在我的机器中，8个字符的输入字符串对于原来的版本需要1.1微妙，然而改进版本花了0.17微妙，快了6.5倍。不仅仅是性能改进了，而且可论证，清晰度也改进了。把原本不可见的Pattern实例变成一个静态final域，使得我们可以给它取一个名字，这样就比正则表达式本身远远有更可读。

如果一个人类初始化，这个类包含改进版本的isRomanNumeral方法，但是这个方法从来没有被调用，那么ROMAN域没有必要初始化。当isRomanNumeral方法第一次被调用时，用懒初始化这个域(条目83)，可以消除这个初始化，这是有可能的，但是不建议这么做。就像通常懒初始化情形一样，这使得实现复杂而没有可测量的性能提升(条目67)。

当一个对象不可变，显然可以被安全复用，但是有其他的情形，是远远不显而易见的，甚至反直觉的。考虑适配器(adapters)[Gamma95]情形，也叫视图(views)。一个适配器是一个对象，代理一个支撑对象，提供了一个可供选择的接口。因为适配器没有它支撑对象之外的状态，所以对于给定对象的给定适配器，没必要创建一个以上的实例。

比如，Map接口的keySet方法返回一个Map对象的Set视图，包含了映射的所有键。乍一看，好像每次调用keySet都会创建一个新的Set实例，但是在给定的Map对象上每次调用keySet，可能返回同一个Set实例。虽然返回的Set实例通常是可变的，但是所有返回对象在功能上相同的：当返回对象之一改变了，所有其他的也会改变，这是因为它们由同一个Map实例支撑。虽然创建keySet视图对象的多个实例，在大部分情况下是无害的，但是这是没必要的而且无益的。

创建不必要的对象的另外一个方式是自动装箱，自动装箱让程序员混合原始值和原始装箱类型，有必要时会自动装箱和拆箱。自动装箱模糊了但是没有消除原始和原始装箱类型的区别。这有微妙的语义的区别和不怎么微妙的性能差异(条目61)。考虑如下方法，它计算所有正整数值之和。为了做这件事，程序用长整形计算，因为整数大小不够容纳所有正整数值之和：

// 相当慢，你能指出对象创建吗？
private static long sum() {
    Long sum = 0L; 
    for (long i = 0; i <= Integer.MAX_VALUE; i++) 
        sum += i;

    return sum;
}

这个程序有正确的答案，但是比本应该的要慢很多，这由于一个字符印刷上的错误。sum变量被声明为一个Long，而不是long，这意味着程序构造了2³¹个没必要的Long实例(长整形i添加到Long sum时大约每次一个)。sum的声明从Long改变到long，在我的机器上运行时间6.3秒减少到0.59秒。这个教训是很清楚的：原始类型优于原始装箱类型，小心无意的自动装箱。

这条不应该误解为暗示：对象创建是很昂贵的，应该避免。相反，创建和回收小对象，它的构造子只做少量的显的工作，是很廉价的，特别是在现代的JVM实现中。创建额外的对象来增强程序的清晰性，简单性和能力，通常是一件好事。

相反，维护你自己的对象池来避免对象创建，是一个坏主意，除非池中的对象是相当重量级的。证明对象池正当的典型例子是数据库链接。建立链接的代价是十分高的，以至于重用这些对象有意义。然而，通常来讲，维护你自己的对象池使你的代码凌乱，增加了内存占用和性能损害。现代JVM实现已经高度优化了垃圾回收，可以很容易比轻量级对象的对象池做的更好。

这个条目对应的是关于防御性拷贝的条目50。当前条目说，“当你需要复用已经存在的对象时不要创建一个新的对象”，然后条目50说，“当你应该创建一个新的对象时不要复用已经存在的对象”。注意，当要求防御性拷贝时重用对象带来的惩罚，远远大于没必要地创建重复对象的惩罚。有要求而不能够生成防御性拷贝，会导致潜伏的缺陷和安全漏洞；创建不必要的对象仅仅影响风格和性能。