加载中...
复用单个对象而不是重复的创建新对象是经常需要做的事情。复用可以加快程序运行速度，也使得代码变得简洁。如果某个对象是不可变的，通常都可以采用复用的方式。
我们看如下的一个例子：
String s = new String("bikini"); // 不要这样使用
上述语句在每次执行的时候都会创建一个String的实例，但是这种创建方式其实没有必要。如果这样的语句出现在循环或者被频繁调用的方法中，会出现数以万计重复的String实例。我们应当采用如下方式定义：
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
String s = "bikini";
这个版本创建的对象是一个单例，它保证了每一个虚拟机内只会出现一个这样的字符对象。
通常情况下，我们可以使用静态工厂方法（参考《Effective Java 第三版》笔记之一 创建静态工厂方法而不是使用构造器）来实现这种情况，而不是采用不可变类的构造函数来创建不可变的变量。例如，字符串转布尔类型的方法我们应该使用Boolean.valueOf(String)而不是Boolean(String)。因为后者在每次调用的时候都会产生一个新的布尔类型对象，而前面的静态工厂方法则是复用了布尔对象。实际上，这个方法已经在Java9中被遗弃了。此外，除了复用不可变对象以外，如果你知道某个可变对象不会被修改的话也应该复用它。
某些对象的创建非常耗费资源，如果你需要重复使用这些对象，应当考虑将之缓存以便于复用。不幸的是，我们通常都无法意识到这个问题。假设你需要写一个方法来判断某个字符串是否是罗马数字，最简单的方法如下：
// 这样的方式不好
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方法，尽管这个方法是最简单的判断某个字符串是否匹配某个正则表达式的方式，但是在关键性能场景下，这个方法不适合复用。因为它会在内部重复地创建Pattern对象，但是实际上这个对象只用了一次。创建完之后它就会被垃圾回收器处理掉。而创建Pattern对象是非常耗时的事情，因为他需要把正则表达式编译成一个有限的状态机。
为了提高性能，我们可以在类被初始化的时候将睁着表达式编译成Pattern对象，并缓存，后面再复用：
// 复用耗费资源的对象以提升性能
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();
}
}
新方法在频繁调用时候会显著提升性能。在作者的机器上，原来的方法在判断8个字节的字符串时候需要1.1微秒，而新方法只需要0.17微秒，提升了6.5倍性能。不仅如此，我们还可以给这个正则一个名字，提高程序的可读性。
如果某个类包含了新的方法isRomanNumeral，并且别初始化了，但是从来没有被调用过。那么ROMAN字段就没有必要被初始化，那么我们可以使用懒加载的方式来定义这个字段。但是我们并不推荐这样做。因为懒加载的实现很复杂，但是并没有明显的证据表明性能提升。
如果某个对象是不可变对象，那么可以放心的复用，但是某些情况下并不是这样。考虑adapters的使用，或者叫做views。一个adapter是后备对象的对象，提供一个备用的接口。由于adapter没有超出其后备对象的状态，因此不需要对给定对象的给定的适配器创建多个实例。
举个例子，Map接口中的keySet方法返回Map对象的View集合，由map中所有的key组成。那么每次调用这个方法的时候按理说应该返回一个新的Set实例，但是对于给定的Map对象，返回可能相同的Set实例。尽管返回的Set实例是一个可变对象，但是所有返回的对象其实都是一样的：当某个返回对象改变的时候，其他所有的都变了，因为他们都是相同Map实例支持。虽然创建keySet视图对象的多个实例在很大程度上是无害的，但它是不必要的并且没有任何好处。
另一个创建不必要对象的场景是自动装箱（autoboxing），它允许程序员将原始类型和装箱的原始类型混合，可以根据需要选择装箱或者不装箱。自动装箱模糊了原始类型和装箱类型，但是并没有消除二者之间的区别。但是它们之间的性能差异却很大。考虑以下情景，需要对所有的int值加和，因为int不能容纳所有int的和，所以需要长算术：
// Hideously slow! Can you spot the object creation?
private static long sum() {
Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++)
sum += i;
return sum;
}
上述程序可以获得正确的结果，但是却很慢。因为sum被声明成Long而不是long，因为这这个程序需要构造$2^{31}$个Long的实例（每次循环都有一个long型的i被加到Long型的sum上）。如果将sum的类型由Long改成long，程序的运行时间从6.3秒降低到了0.59秒。这个经验表明，尽量使用原始类型，而不是装箱类型，尽量舍弃不必要的自动装箱。
让大家避免创建耗费资源的变量并不是告诉大家创建对象是耗费时间的应该被舍弃。相反，在现在的JVM实现上，创建和重新申明不复杂构造器的小型对象一点都不耗费资源。创建额外的对象来保证可读性、简单性是非常值得的一件事情。
反过来，维护你自己的对象池来避免创建对象是个坏主意，除非池中的对象很重量级。经典的对象池就是数据库连接池。因为创建连接是非常耗费时间的，重用这些连接是很有意义的。一般来说，维护你自己的对象池会导致代码混乱、增加内存占用并损害性能。现代JVM实现有高度优化的垃圾回收器可以很轻松的帮你胜任对轻量级对象的管理。
注意，当在保护性拷贝（defensive copying）的场合时，就比重复使用对象较好。未能在必要时制作保护性拷贝会导致一些错误和安全漏洞;但不必要地创建对象只会影响代码可读性和性能。