使用静态工厂方法的优势与应用

需积分: 50 190 浏览量更新于2024-07-09 收藏 3.2MB PDF 举报

"effective-java.pdf" Effective Java 是一本经典的编程书籍，由Joshua Bloch撰写，主要探讨了如何编写高质量的Java代码。以下是对标题和描述中提到的一些关键知识点的详细解释： 1. 静态工厂方法：静态工厂方法是一种在类中提供静态方法来创建对象的方式，而不是通过公有构造函数。它们可以被看作是类的内部工具，用于生成类的实例。静态工厂方法的一个关键特性是它们具有名称，这使得它们比构造方法更具可读性，尤其是在参数描述不明确的情况下。 2. 名称的重要性：静态工厂方法的命名能够增加代码的可理解性。例如，如果一个构造方法的参数难以直接反映创建的对象特性，一个具有描述性的静态工厂方法名称可以提高代码的可读性和易用性。 3. 构造方法的限制：一个类只能有一个给定签名的构造方法，这可能导致在需要多个相似构造方法时产生混淆。而静态工厂方法可以克服这个限制，通过不同的方法名提供类似功能，减少使用上的困扰。 4. 对象复用：静态工厂方法的一个显著优势是它们可以选择在多次调用时返回相同的实例，这对于不可变类特别有用。例如，`Boolean.valueOf(boolean)`方法就遵循这种模式，它不会为相同的布尔值创建新的对象，而是返回已经存在的对象，从而节省资源。 5. 性能优化：在创建对象成本较高的情况下，静态工厂方法可以实现对象池或缓存机制，通过重用预先构建的实例来提升性能。这是一种实现轻量级 Flyweight 模式的策略，它减少了内存开销并提高了程序效率。 6. 控制实例化：通过静态工厂方法，类可以更好地控制其实例的创建，甚至可以实现单例模式。这种方法提供了更多的灵活性，可以在类的设计中引入更复杂的实例管理策略。 7. 类的非公开构造器：使用静态工厂方法可以使类的构造器保持私有，从而阻止外部直接实例化，这有助于保持类的封装性，并确保只有通过指定的静态工厂方法才能创建对象。 8. 泛型和枚举的使用：静态工厂方法也常与泛型和枚举结合使用，比如在创建参数化的集合实例或提供枚举类型的实例时。 9. 可见性：静态工厂方法可以有不同的可见性，允许类在某些情况下只向其包内或者子类开放实例化。 Effective Java 提倡使用静态工厂方法作为构造类实例的一种替代方案，以提高代码的灵活性、可读性和性能。这种实践是面向对象设计中的一个重要技巧，有助于编写出更加优雅、高效和易于维护的Java代码。

如果经常调用， isRomanNumeral 的改进版本的性能会显著提升。在我的机器上，原始版本在输

入 8 个字符的字符串上需要 1.1 微秒，而改进的版本则需要 0.17 微秒，速度提高了 6.5 倍。性能上不

仅有所改善，而且更明确清晰了。为不可见的 Pattern 实例创建静态 final 修饰的属性，并允许给它一

个名字，这个名字比正则表达式本身更具可读性。

如果包含 isRomanNumeral 方法的改进版本的类被初始化，但该方法从未被调用，则 ROMAN 属

性则没必要初始化。在第一次调用 isRomanNumeral 方法时，可以通过延迟初始化（ lazily

initializing）属性（详见第 83 条）来排除初始化，但一般不建议这样做。延迟初始化常常会导致实现

复杂化，而性能没有可衡量的改进（详见第 67 条）。

当一个对象是不可变的时，很明显它可以被安全地重用，但是在其他情况下，它远没有那么明显，

甚至是违反直觉的。考虑适配器（adapters）的情况[Gamma95]，也称为视图（views）。一个适配器

是一个对象，它委托一个支持对象（backing object），提供一个可替代的接口。由于适配器没有超出

其支持对象的状态，因此不需要为给定对象创建多个给定适配器的实例。

例如，Map 接口的 keySet 方法返回 Map 对象的 Set 视图，包含 Map 中的所有 key。天真地

说，似乎每次调用 keySet 都必须创建一个新的 Set 实例，但是对给定 Map 对象的 keySet 的每次

调用都返回相同的 Set 实例。尽管返回的 Set 实例通常是可变的，但是所有返回的对象在功能上都是相

同的：当其中一个返回的对象发生变化时，所有其他对象也都变化，因为它们全部由相同的 Map 实例

支持。虽然创建 keySet 视图对象的多个实例基本上是无害的，但这是没有必要的，也没有任何好

处。

另一种创建不必要的对象的方法是自动装箱（auto boxing），它允许程序员混用基本类型和包装的

基本类型，根据需要自动装箱和拆箱。自动装箱模糊不清，但不会消除基本类型和装箱基本类型之间的

区别。有微妙的语义区别和不那么细微的性能差异（详见第 61 条）。考虑下面的方法，它计算所有正

整数的总和。要做到这一点，程序必须使用 long 类型，因为 int 类型不足以保存所有正整数的总

和：

这个程序的结果是正确的，但由于写错了一个字符，运行的结果要比实际慢很多。变量 sum 被声

明成了 Long 而不是 long ，这意味着程序构造了大约 2

不必要的 Long 实例（大约每次往 Long

类型的 sum 变量中增加一个 long 类型构造的实例），把 sum 变量的类型由 Long 改为 long ，

在我的机器上运行时间从 6.3 秒降低到 0.59 秒。这个教训很明显：优先使用基本类型而不是装箱的基本

类型，也要注意无意识的自动装箱。

这个条目不应该被误解为暗示对象创建是昂贵的，应该避免创建对象。相反，使用构造方法创建和

回收小的对象是非常廉价，构造方法只会做很少的显示工作，尤其是在现代 JVM 实现上。创建额外的

对象以增强程序的清晰度，简单性或功能性通常是件好事。

// 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;

}

相反，除非池中的对象非常重量级，否则通过维护自己的对象池来避免对象创建是一个坏主意。对

象池的典型例子就是数据库连接。建立连接的成本非常高，因此重用这些对象是有意义的。但是，一般

来说，维护自己的对象池会使代码混乱，增加内存占用，并损害性能。现代 JVM 实现具有高度优化的

垃圾收集器，它们在轻量级对象上轻松胜过此类对象池。

这个条目的对应点是针对条目 50 的防御性复制（defensive copying）。目前的条目说：「当你应

该重用一个现有的对象时，不要创建一个新的对象」，而条目 50 说：「不要重复使用现有的对象，当

你应该创建一个新的对象时。」请注意，重用防御性复制所要求的对象所付出的代价，要远远大于不必

要地创建重复的对象。未能在需要的情况下防御性复制会导致潜在的错误和安全漏洞；而不必要地创建

对象只会影响程序的风格和性能。

7. 消除过期的对象引用

如果你从使用手动内存管理的语言（如 C 或 C++）切换到像 Java 这样的带有垃圾收集机制的语

言，那么作为程序员的工作就会变得容易多了，因为你的对象在使用完毕以后就自动回收了。当你第一

次体验它的时候，它就像魔法一样。这很容易让人觉得你不需要考虑内存管理，但这并不完全正确。

考虑以下简单的栈实现：

// Can you spot the "memory leak"?

public class Stack {

private Object[] elements;

private int size = 0;

private static final int DEFAULT_INITIAL_CAPACITY = 16;

public Stack() {

elements = new Object[DEFAULT_INITIAL_CAPACITY];

}

public void push(Object e) {

ensureCapacity();

elements[size++] = e;

}

public Object pop() {

if (size == 0)

throw new EmptyStackException();

return elements[--size];

}

/**

* Ensure space for at least one more element, roughly

* doubling the capacity each time the array needs to grow.

private void ensureCapacity() {

if (elements.length == size)

这个程序没有什么明显的错误（但是对于泛型版本，请参阅条目 29）。你可以对它进行详尽的测

试，它都会成功地通过每一项测试，但有一个潜在的问题。笼统地说，程序有一个「内存泄漏」，由于

垃圾回收器的活动的增加，或内存占用的增加，静默地表现为性能下降。在极端的情况下，这样的内存

泄漏可能会导致磁盘分页（disk paging），甚至导致内存溢出（OutOfMemoryError）的失败，但是这

样的故障相对较少。

那么哪里发生了内存泄漏？如果一个栈增长后收缩，那么从栈弹出的对象不会被垃圾收集，即使使

用栈的程序不再引用这些对象。这是因为栈维护对这些对象的过期引用（obsolete references）。过期

引用简单来说就是永远不会解除的引用。在这种情况下，元素数组「活动部分（active portion）」之

外的任何引用都是过期的。活动部分是由索引下标小于 size 的元素组成。

垃圾收集语言中的内存泄漏（更适当地称为无意的对象保留 unintentional object retentions）是隐

蔽的。如果无意中保留了对象引用，那么不仅这个对象排除在垃圾回收之外，而且该对象引用的任何对

象也是如此。即使只有少数对象引用被无意地保留下来，也可以阻止垃圾回收机制对许多对象的回收，

这对性能产生很大的影响。

这类问题的解决方法很简单：一旦对象引用过期，将它们设置为 null。在我们的 Stack 类的情景

下，只要从栈中弹出，元素的引用就设置为过期。 pop 方法的修正版本如下所示：

取消过期引用的另一个好处是，如果它们随后被错误地引用，程序立即抛出

NullPointerException 异常，而不是悄悄地做继续做错误的事情。尽可能快地发现程序中的错误是有

好处的。

当程序员第一次被这个问题困扰时，他们可能会在程序结束后立即清空所有对象引用。这既不是必

要的，也不是可取的；它不必要地搞乱了程序。清空对象引用应该是例外而不是规范。消除过期引用的

最好方法是让包含引用的变量超出范围。如果在最近的作用域范围内定义每个变量（详见第 57 条），

这种自然就会出现这种情况。

那么什么时候应该清空一个引用呢？ Stack 类的哪个方面使它容易受到内存泄漏的影响？简单地

说，它管理自己的内存。存储池（storage pool）由 elements 数组的元素组成（对象引用单元，而不

是对象本身）。数组中活动部分的元素 (如前面定义的) 被分配，其余的元素都是空闲的。垃圾收集器没

有办法知道这些；对于垃圾收集器来说， elements 数组中的所有对象引用都同样有效。只有程序员知

道数组的非活动部分不重要。程序员可以向垃圾收集器传达这样一个事实，一旦数组中的元素变成非活

动的一部分，就可以手动清空这些元素的引用。

elements = Arrays.copyOf(elements, 2 * size + 1);

}

public Object pop() {

if (size == 0)

throw new EmptyStackException();

Object result = elements[--size];

elements[size] = null; // Eliminate obsolete reference

return result;

}

一般来说，当一个类自己管理内存时，程序员应该警惕内存泄漏问题。每当一个元素被释放时，元

素中包含的任何对象引用都应该被清除。

另一个常见的内存泄漏来源是缓存。一旦将对象引用放入缓存中，很容易忘记它的存在，并且在它

变得无关紧要之后，仍然保留在缓存中。对于这个问题有几种解决方案。如果你正好想实现了一个缓

存：只要在缓存之外存在对某个项（entry）的键（key）引用，那么这项就是明确有关联的，就可以用

WeakHashMap 来表示缓存；这些项在过期之后自动删除。记住，只有当缓存中某个项的生命周期是由

外部引用到键（key）而不是值（value）决定时， WeakHashMap 才有用。

更常见的情况是，缓存项有用的生命周期不太明确，随着时间的推移一些项变得越来越没有价值。

在这种情况下，缓存应该偶尔清理掉已经废弃的项。这可以通过一个后台线程 (也许是

ScheduledThreadPoolExecutor ) 或将新的项添加到缓存时顺便清理。 LinkedHashMap 类使用它的

removeEldestEntry 方法实现了后一种方案。对于更复杂的缓存，可能直接需要使用

java.lang.ref 。

第三个常见的内存泄漏来源是监听器和其他回调。如果你实现了一个 API，其客户端注册回调，但

是没有显式地撤销注册回调，除非采取一些操作，否则它们将会累积。确保回调是垃圾收集的一种方法

是只存储弱引用（weak references），例如，仅将它们保存在 WeakHashMap 的键（key）中。

因为内存泄漏通常不会表现为明显的故障，所以它们可能会在系统中保持多年。通常仅在仔细的代

码检查或借助堆分析器（heap profiler）的调试工具才会被发现。因此，学习如何预见这些问题，并防

止这些问题发生，是非常值得的。



8. 避免使用 Finalizer 和 Cleaner 机制

Finalizer 机制是不可预知的，往往是危险的，而且通常是不必要的。它们的使用会导致不稳定的行

为，糟糕的性能和移植性问题。 Finalizer 机制有一些特殊的用途，我们稍后会在这个条目中介绍，但是

通常应该避免它们。从 Java 9 开始，Finalizer 机制已被弃用，但仍被 Java 类库所使用。 Java 9 中

Cleaner 机制代替了 Finalizer 机制。 Cleaner 机制不如 Finalizer 机制那样危险，但仍然是不可预测，运

行缓慢并且通常是不必要的。

提醒 C++程序员不要把 Java 中的 Finalizer 或 Cleaner 机制当成的 C++ 析构函数的等价物。在

C++ 中，析构函数是回收对象相关资源的正常方式，是与构造方法相对应的。在 Java 中，当一个对象

变得不可达时，垃圾收集器回收与对象相关联的存储空间，不需要开发人员做额外的工作。 C++ 析构

函数也被用来回收其他非内存资源。在 Java 中，try-with-resources 或 try-finally 块用于此目的（详见

第 9 条）。

Finalizer 和 Cleaner 机制的一个缺点是不能保证他们能够及时执行[JLS，12.6]。在一个对象变得无

法访问时，到 Finalizer 和 Cleaner 机制开始运行时，这期间的时间是任意长的。这意味着你永远不应

该 Finalizer 和 Cleaner 机制做任何时间敏感（time-critical）的事情。例如，依赖于 Finalizer 和 Cleaner

机制来关闭文件是严重的错误，因为打开的文件描述符是有限的资源。如果由于系统迟迟没有运行

Finalizer 和 Cleaner 机制而导致许多文件被打开，程序可能会失败，因为它不能再打开文件了。

及时执行 Finalizer 和 Cleaner 机制是垃圾收集算法的一个功能，这种算法在不同的实现中有很大的

不同。程序的行为依赖于 Finalizer 和 Cleaner 机制的及时执行，其行为也可能大不不同。这样的程序

完全可以在你测试的 JVM 上完美运行，然而在你最重要的客户的机器上可能运行就会失败。

延迟终结（finalization）不只是一个理论问题。为一个类提供一个 Finalizer 机制可以任意拖延它的

实例的回收。一位同事调试了一个长时间运行的 GUI 应用程序，这个应用程序正在被一个

OutOfMemoryError 错误神秘地死掉。分析显示，在它死亡的时候，应用程序的 Finalizer 机制队列上有

成千上万的图形对象正在等待被终结和回收。不幸的是，Finalizer 机制线程的运行优先级低于其他应用

程序线程，所以对象被回收的速度低于进入队列的速度。语言规范并不保证哪个线程执行 Finalizer 机

制，因此除了避免使用 Finalizer 机制之外，没有轻便的方法来防止这类问题。在这方面， Cleaner 机制

比 Finalizer 机制要好一些，因为 Java 类的创建者可以控制自己 cleaner 机制的线程，但 cleaner 机制仍

然在后台运行，在垃圾回收器的控制下运行，但不能保证及时清理。

Java 规范不能保证 Finalizer 和 Cleaner 机制能及时运行；它甚至不能能保证它们是否会运行。当一

个程序结束后，一些不可达对象上的 Finalizer 和 Cleaner 机制仍然没有运行。因此，不应该依赖于

Finalizer 和 Cleaner 机制来更新持久化状态。例如，依赖于 Finalizer 和 Cleaner 机制来释放对共享资源

（如数据库）的持久锁，这是一个使整个分布式系统陷入停滞的好方法。

不要相信 System.gc 和 System.runFinalization 方法。他们可能会增加 Finalizer 和 Cleaner

机制被执行的几率，但不能保证一定会执行。曾经声称做出这种保证的两个方法：

System.runFinalizersOnExit 和它的孪生兄弟 Runtime.runFinalizersOnExit ，包含致命的缺陷，

并已被弃用了几十年[ThreadStop]。

Finalizer 机制的另一个问题是在执行 Finalizer 机制过程中，未捕获的异常会被忽略，并且该对象的

Finalizer 机制也会终止 [JLS, 12.6]。未捕获的异常会使其他对象陷入一种损坏的状态（corrupt state）。

如果另一个线程试图使用这样一个损坏的对象，可能会导致任意不确定的行为。通常情况下，未捕获的

异常将终止线程并打印堆栈跟踪（ stacktrace），但如果发生在 Finalizer 机制中，则不会发出警告。

Cleaner 机制没有这个问题，因为使用 Cleaner 机制的类库可以控制其线程。

使用 finalizer 和 cleaner 机制会导致严重的性能损失。在我的机器上，创建一个简单的

AutoCloseable 对象，使用 try-with-resources 关闭它，并让垃圾回收器回收它的时间大约是 12 纳

秒。使用 finalizer 机制，而时间增加到 550 纳秒。换句话说，使用 finalizer 机制创建和销毁对象的速

度要慢 50 倍。这主要是因为 finalizer 机制会阻碍有效的垃圾收集。如果使用它们来清理类的所有实例

（在我的机器上的每个实例大约是 500 纳秒），那么 cleaner 机制的速度与 finalizer 机制的速度相当，

但是如果仅将它们用作安全网（safety net），则 cleaner 机制要快得多，如下所述。在这种环境下，创

建，清理和销毁一个对象在我的机器上需要大约 66 纳秒，这意味着如果你不使用安全网的话，需要支

付 5 倍（而不是 50 倍）的保险。

finalizer 机制有一个严重的安全问题：它们会打开你的类来进行 finalizer 机制攻击。finalizer 机制

攻击的想法很简单：如果一个异常是从构造方法或它的序列化中抛出的—— readObject 和

readResolve 方法（第 12 章）——恶意子类的 finalizer 机制可以运行在本应该「中途夭折（died on

the vine）」的部分构造对象上。finalizer 机制可以在静态字属性记录对对象的引用，防止其被垃圾收

集。一旦记录了有缺陷的对象，就可以简单地调用该对象上的任意方法，而这些方法本来就不应该允许

存在。从构造方法中抛出异常应该足以防止对象出现；而在 finalizer 机制存在下，则不是。这样的攻击

会带来可怕的后果。Final 类不受 finalizer 机制攻击的影响，因为没有人可以编写一个 final 类的恶意子

类。为了保护非 final 类不受 finalizer 机制攻击，编写一个 final 的 finalize 方法，它什么都不做。

剩余264页未读，继续阅读

NBlpp

粉丝: 0
资源: 1

使用静态工厂方法的优势与应用

Effective Java读书笔记.pdf

Effective Java第三版1

Effective Java.zip

effective-go.pdf(文字版)

OCP.Java.SE.8.Programmer.II.Exam.Guide.Exam.1Z0-809.7th.2018.pdf

effective.java.3rd.edition 中文pdf

Effective.Enterprise.Java中文版.pdf

Effective.Enterprise.Java.中文版PDF和TXT下载

Effective.Enterprise.Java.中文版 高清pdf 下载

effective-java-3rd-chinese

最新资源

Effective.Enterprise.Java.中文版高清pdf 下载