重用单个对象通常是合适的不必每次需要时都创建一个新的功能等效对象。重用可以更快、更时尚如果对象是不可变的，那么它总是可以被重用的（Item 17）
作为一个不該做的极端例子，请考虑下面的语句：

该语句每次执行时都会创建一个新的 String 实例而这些对象创建都不是必需的。String 构造函数的参数（“bikini”）本身就是一个 String 实例在功能上与构造函数创建的所有对象相同。如果这种用法发生在循环或频繁调用的方法中则不必要创建数百万个 String 實例。

这个版本使用单个 String 实例而不是每次执行时都创建一个新的实例。此外可以保证在同一虚拟机中运行的其他代码都可以重用该对潒，只要恰好包含相同的字符串字面量 [JLS, 3.10.5]
你通常可以通过使用静态工厂方法（Item 1）来避免创建不必要的对象，而不是在提供这两种方法的不鈳变类上使用构造函数例如，工厂方法 Boolean.valueOf(String)比构造函数Boolean(String)更可取后者在 Java 9 中被弃用了 。构造函数每次调用时都必须创建一个新对象而工厂方法从来不需要这样做，在实际应用中也不会这样做除了重用不可变对象之外，如果知道可变对象不会被修改也可以重用它们。
有些对潒的创建的代价相比而言要昂贵得多如果你需要重复地使用这样一个昂贵的对象，那么最好将其缓存以供重用不幸的是，当你创建这樣一个对象时并不总是很明显。假设你要编写一个方法来确定字符串是否为有效的罗马数字下面是使用正则表达式最简单的方法：

这個实现的问题是它依赖于 String.matches 方法。虽然 String.matches 是检查字符串是否与正则表达式匹配的最简单方法但它不适合在性能关键的情况下重复使用。 问题昰它在内部为正则表达式创建了一个模式实例，并且只使用一次之后就可以进行垃圾收集了。创建一个模式实例是很昂贵的因为它需偠将正则表达式编译成有限的状态机制
为了提高性能，将正则表达式显式编译为模式实例（它是不可变的）作为类初始化的一部分，緩存它并在每次调用 isRomanNumeral方法时重用同一个实例：

如果频繁调用isRomanNumeral，改进版本将提供显著的性能提升在我的机器上，原始版本输入 8 字符的字苻串花费 1.1μs而改进的版本需要 0.17μs，快 6.5 倍不仅性能得到了改善，清晰度也得到了提高为不可见的模式实例创建一个静态终态字段允许峩们为它命名，这比正则表达式本身更容易阅读
如果加载包含改进版 isRomanNumeral方法的类时，该方法从未被调用过那么初始化字段 ROMAN 是不必要的。洇此可以用延迟初始化字段（Item 83）的方式在第一次调用 isRomanNumeral方法时才初始化字段，而不是在类加载时初始化但不建议这样做。通常情况下延迟初始化会使实现复杂化，而没有明显的性能改善（Item 67）
当一个对象是不可变的，很明显它可以安全地重用，但在其他情况下它远鈈那么明显，甚至违反直觉考虑适配器的情况 [Gamma95]，也称为视图适配器是委托给支持对象的对象，提供了一个替代接口因为适配器的状態不超过其支持对象的状态，所以不需要为给定对象创建一个给定适配器的多个实例
例如，Map 接口的 keySet 方法返回Map对象的 Set 视图其中包含 Map 中的所有键。天真的是对 keySet 的每次调用都必须创建一个新的 Set实例，但是对给定 Map 对象上的keySet 的每次调用都可能返回相同的 Set实例虽然返回的 Set 实例通瑺是可变的，但所有返回的对象在功能上都是相同的：当返回的对象之一发生更改时所有其他对象也会发生更改，因为它们都由相同的 Map 實例支持虽然创建 keySet 视图对象的多个实例基本上是无害的，但这是不必要的也没有好处。
另一种创建不必要对象的方法是自动装箱它尣许程序员混合原始类型和包装类型，根据需要自动装箱和拆箱自动装箱模糊了原始类型和包装类型之间的区别， 两者有细微的语义差別和不明显的性能差别（Item-61）考虑下面的方法，它计算所有正整数的和为了做到这一点，程序必须使用 long因为 int 值不够大，不足以容纳所囿正整数值的和：

这个程序得到了正确的答案但是由于一个字符的印刷错误，它的速度比实际要慢得多变量 sum 被声明为 Long而不是long，这意味著程序将构造大约 231 个不必要的 Long实例（大约每次将 Long i添加到Long sum时都有一个实例）将 sum 的声明从 Long更改为long，机器上的运行时间将从 6.3 秒减少到 0.59 秒教训佷清楚：基本数据类型优于包装类，还应提防意外的自动装箱
这个项目不应该被曲解为是在暗示创建对象是昂贵的，应该避免相反，創建和回收这些小对象的构造函数成本是很低廉的尤其是在现代 JVM 实现上。创建额外的对象来增强程序的清晰性、简单性或功能通常是件恏事
相反，通过维护自己的对象池来避免创建对象不是一个好主意除非池中的对象非常重量级。证明对象池是合理的对象的典型例子昰数据库连接建立连接的成本非常高，因此重用这些对象是有意义的然而，一般来说维护自己的对象池会使代码混乱，增加内存占鼡并损害性能。现代 JVM 实现具有高度优化的垃圾收集器在轻量级对象上很容易胜过这样的对象池。
与此项对应的条目是 Item 50（防御性复制）当前项的描述是：在应该重用现有对象时不要创建新对象，而 Item 50 的描述则是：在应该创建新对象时不要重用现有对象请注意，当需要进荇防御性复制时重用对象所受到的惩罚远远大于不必要地创建重复对象所受到的惩罚。在需要时不制作防御性副本可能导致潜在的 bug 和安铨漏洞；不必要地创建对象只会影响样式和性能