@@ -438,4 +438,87 @@ public Object pop() {
438438
439439** 内存泄漏的第三个常见来源是监听器和其它回调** 。如果你实现了一个 API，客户端在这个 API 中注册回调，却没有显示地取消注册，那么除非你采取某些动作，否则它们就会聚集。确保回调立即被当作垃圾回收的最佳方法是只保存它们的软引用（` weak reference ` ），例如，只将它们保存成 WeakHashMap 中的键。
440440
441- 由于内存泄漏通常不会表现成明显的失败，所以它们可以在一个系统中存在很多年。往往只有通过代码检查，或者借助于 Heap 剖析工具（` Heap Profiler ` ）才可以发现内存泄漏问题。所以，如果我们能在内存泄漏发生之前就知道如何预测和分析此类问题，并预防和阻止它们发生，那是最好不过了。
441+ 由于内存泄漏通常不会表现成明显的失败，所以它们可以在一个系统中存在很多年。往往只有通过代码检查，或者借助于 Heap 剖析工具（` Heap Profiler ` ）才可以发现内存泄漏问题。所以，如果我们能在内存泄漏发生之前就知道如何预测和分析此类问题，并预防和阻止它们发生，那是最好不过了。
442+
443+ ### 第 7 条：避免使用终结方法
444+ ** 终结方法（` finalizer ` ）通常是不可预测的，也是很危险的，一般情况下是不必要的** 。使用终结方法会有很多缺点：会导致行为不稳定、降低性能，以及可移植性问题。当然，终结方法也有其可用之处，该条目后面会进行介绍；但是根据经验，还是应该避免使用终结方法。
445+
446+ C++ 程序员被告知“不要把终结方法当作是 C++ 中析构器（` destructors ` ）的对应物”。在 C++ 中，析构器是回收一个对象所占用资源的常规方法，是构造器所必须的对应物。在 Java 中，当一个对象变得不可到达时，垃圾回收器会回收与该对象相关联的存储空间，并不需要程序员做专门的工作。C++ 中的析构器也可以被用来回收其他的内存资源。而在 Java 中，一般用 try-finally 块来完成类似的工作。
447+
448+ 终结方法的缺点在于不能保证会被及时地执行[ JLS，12.6] 。从一个对象变得不可到达开始，到它的终结方法被执行，所花费的这段时间是任意长的。这意味着，注重时间（` time-critical ` ）的任务是不应该由终结方法来完成。例如，用终结方法来关闭已经打开的文件，这是严重错误，因为打开文件的描述符是一种有限的资源。由于 JVM 会延时执行终结方法，所以大量的文件会保留在打开状态，当一个程序再不能打开文件的时候，它可能会运行失败。
449+
450+ 及时地执行终结方法正是垃圾回收算法的一个主要功能，这种算法在不同的 JVM 实现中会大相径庭。如果程序依赖于终结方法被执行的时间点，那么这个程序在不同的 JVM 运行的表现可能会截然不同。一个程序可能在你测试的 JVM 平台上运行的非常好，但是在你最重要顾客的 JVM 平台上却根本无法运行，这是完成可能的。
451+
452+ 延迟终结过程并不只是一个理论问题。在很少见的情况下，为类提供终结方法，可能会随意地延迟其实例的回收过程。一位同事最近在调试一个长期运行的 GUI 应用程序的时候，该应用程序莫名其妙地出现 OutOfMemoryError 错误而死掉。分析表明，该应用程序死掉的时候，其终结方法队列中有数千个图像对象正在被等待终结和回收。遗憾的是，终结方法线程的优先级比该程序的其它线程的要低很多，所以，图形对象的终结速度达不到进入队列的速度。Java 语言规范并不保证哪个线程将会执行终结方法，所以，除了不使用终结方法以外，并没有很轻便的办法能够避免这样的问题。
453+
454+ Java 语言规范不仅不保证终结方法会被及时地执行，而且根本就不保证它们会被执行。当一个程序终止的时候，某些已经无法访问的对象上的终结方法却根本没有被执行，这是完全有可能的。结论是：** 不应该依赖终结方法来更新重要的持久状态** 。例如，依赖终结方法来解释共享资源（比如数据库）上的永久锁，很容易让整个分布式系统垮掉。
455+
456+ 不要被 System.gc 和 System.runFinalization 这两个方法所诱惑，它们确实增加了终结方法被执行的机会，但是它们并不保证终结方法一定会被执行。唯一声称保证终结方法被执行的方法是 System.runFinalizersOnExit，以及它臭名昭著的孪生兄弟 RunTime.runFinalizersOnExit。这两个方法都有致命的缺陷，已经被废弃了[ ThreadStop] 。
457+
458+ 当你并不确定是否应该避免使用终结方法的时候，这里还有一种值得考虑的情形：如果未被捕获的异常在终结方法中被抛出来，那么这种异常可以被忽略，并且该对象的终结过程也会终止[ JLS，12.6] 。未被捕获的异常会使对象处于破坏的状态（a corrupt state），如果另一个线程企图使用这种被破坏的对象，则可能发生任何不确定的行为。在正常情况下，未被捕获的异常会使线程终止，并打印出栈轨迹（` Stack Trace ` ），但是，如果发生在终结方法之中，则不会如此，甚至连警告都不会打印出来。
459+
460+ 还有一点：** 使用终结方法有一个非常严重的（` Severe ` ）性能损失** 。在我的机器上，创建和销毁一个简单对象的时间大约是 5.6ns，增加一个终结方法使时间增加到了 2400ns。换句话说，用终结方法创建或销毁对象大约慢了 430 倍。
461+
462+ 那么，如果类中封装的资源（例如文件或者线程）确实需要终止，应该怎么做才能不编写终结方法呢？只需** 提供一个显示的终止方法** ，并要求该类的客户端在每个实例不再有用的时候调用这个方法。值得提及的一个细节是，该实例必须记录下自己是否已经被终结了：显示的终止方法必须在一个私有域中记录下“该对象已经不再有效”。如果这些方法是在对象已经被终止之后调用，其它的方法就必须检查这个域，并抛出 IllegalStateException 异常。
463+
464+ 显示终止方法的典型例子是 InputStream、OutputStream 和 java.sql.Connection 上的 close 方法。另一个例子是 java.utils.Timer 上的 cancel 方法，它执行必要的状态改变，使得与 Timer 实例相关联的该线程温和地终止自己。java.awt 中的例子还包括 Graphics.dispose 和 Window.dispose。这些方法通常由于性能不好而不被人们关注。一个相关的方法是 Image.flush，它会释放所有与 Image 实例相关的资源，但是该实例仍然处于可用的状态，如果有必要的话，会重新分配资源。
465+
466+ ** 显示的终止方法通常与 try-finally 结构联合起来使用，以确保及时终止** 。在 finally 子句内部调用显示的终止方法，可以确保即使在使用对象的时候有异常抛出，该终止方法也会执行：
467+
468+ ``` java
469+
470+ // try-finally block guarantees execution of termination method
471+ Foo foo = new Foo (... );
472+ try {
473+ // Do what must be done with foo
474+ ...
475+ } finally {
476+ foo. terminate(); // Explicitt termination method
477+ }
478+
479+ ```
480+
481+ 那么终结方法有什么好处呢？它们有两种合法用途。第一种用途是，当对象的所有者忘记调用前面段落建议的显示终止方法时，终结方法可以充当“安全网（` safety net ` ）”。虽然这样做并不是保证终结方法会被及时的调用，但是在客户端无法通过调用显式的终止方法来正常结束操作的情况下（希望这种情况尽可能少地发生），迟一点释放关键资源总比永远不释放要好。但是如果终结方法发现资源还未被终止，则应该在日志中记录一条警告，因为这表示客户端代码中的一个 Bug，应该得到修复。如果你正考虑编写这样的安全网终结方法，就要认真考虑清楚，这种额外的保护是否值得你付出这份额外的代价。
482+
483+ 显示终止方法模式的示例中所示的四个类（` FileInputStream ` 、` FileOutputStream ` 、` Timer ` 和 ` Connection ` ），都具有终结方法，当它们的终止方法未能被调用的情况下，这些终止方法充当了安全网。
484+
485+ 终结方法的第二种合理用途与对象的本地对等体（` native peer ` ）有关。本地对等体是一个本地对象（` native object ` ），普通方法通过本地方法（` native method ` ）委托给一个本地对象。因为本地对等体不是一个普通对象，所以垃圾回收器不会知道它，当它的 Java 对等体回收的时候，它不会被回收。在本地对等体并不拥有关键资源的前提下，终结方法正是执行这项任务最合适的工具。如果本地对等体拥有被及时终止的资源，那么该类就应该拥有一个显式的终止方法，如前所述。终止方法应该完成完成所有必要的工作以便释放关键的资源。终止方法可以是本地方法，或则它也可以调用本地方法。
486+
487+ 值得注意的最重要的一点是，“终结方法链（` finalizer chaining ` ）”并不会被自动执行。如果类（不是 Object）有终结方法，并且子类覆盖了终结方法，子类的终结方法就必须手工调用超类的终结方法。你应该在一个 try 块中终结子类，并在相应的 finally 块中调用超类的终结方法。这样做可以保证：即使子类的终结过程抛出异常，超类的终结方法也会得到执行。反之亦然。代码示例如下。注意这个示例使用了 Override 注解（` @Override ` ），这是 Java 1.5 发行版本将它增加到 Java 平台中的。你现在可以不管 Override 注解，或者到第 36 条查阅一下它们是什么意思：
488+
489+ ``` java
490+
491+ // Manual finalizer chaining
492+ @Override
493+ protected void finalize() throws Throwable {
494+ try {
495+ // Finalize subclass state
496+ } finally {
497+ super . finalize();
498+ }
499+ }
500+
501+ ```
502+
503+ 如果子类实现者覆盖了超类的终结方法，但是忘了手工调用超类的终结方法（或者有意选择不调用超类的终结方法），那么超类的终结方法将会永远也不会被调用到。要防范这样粗心大意或者恶意的子类是有可能的，代价就是为每个被终结的对象创建了一个附加的对象。不是把终结方法放在要求终结处理的类中，而是把终结方法在一个匿名的类（见第 22 条）中，该匿名类的唯一用途就是终结它的外围实例（`enclosing instance`）。该匿名类的单个实例被称为**终结方法守卫者（`finalizer guardian`）**，外围类的每个实例都会创建这样一个守卫者。外围实例在它的私有实例域中保存这一个对其终结方法守卫者的唯一引用，因此终结方法守卫者与外围实例可以同时启动终结过程。当守卫者被终结的时候，它执行外围实例所期望的终结行为，就好像它的终结方法是外围对象上的一个方法一样：
504+
505+ ``` java
506+
507+ // Finalizer Guardian idiom
508+ public class Foo {
509+ // Sole purpose of this object is to finalize outer Foo object
510+ private final object finalizerGuardian = new Object () {
511+ @Override
512+ protect void finalize () throws Throwable {
513+ ... // Finalize outer Foo object
514+ }
515+ };
516+
517+ ... // Remainder omitted
518+ }
519+
520+ ```
521+
522+ 注意，共有类 Foo 并没有终结方法（除了它从 Object 中继承了一个无关紧要的之外），所以子类的终结方法是否调用 super.finalize() 并不重要。对于每一个带有终结方法的非 final 共有类，都应该考虑使用这种方法。
523+
524+ 总之，除非是作为安全网，或者是为了终止非关键的本地资源，否则请不要使用终结方法。在很少见的情况下，既然使用了终结方法，就要记住调用 super.finalize。如果用终结方法作为安全网，要记得记录终结方法的非法用法。最后，如果需要把终结方法与共有的非 final 类关联起来，请考虑使用终结方法守卫者，以确保即使子类的终结方法未能调用 super.finalize，该终结方法也会被执行。
0 commit comments