建议：避免使用终结方法。

        终结方法（finalizer）通常是不可预测的，也是很危险的，一般情况下是不必要的。使用终结方法会导致行为不稳定、降低性能，以及可移植性问题。

        终结方法的缺点在于不能保证会被及时的执行。从一个对象变得不可到达开始，到它的终结方法被执行，所花费的这段时间是任意长的。这意味着，注重时间（time-critical）的任务不应该由终结方法来完成的。例如，用终结方法来关闭已经打开的文件，这是严重错误，因为打开文件的描述符是一种很有限的资源。由于JVM会延迟执行终结方法，所以大量的文件会保留在打开状态，当一个程序再不能打开文件的时候，他可能会运行失败。

        Java语言规范不仅不保证终结方法会被及时的执行，而且根本就不保证他们会被执行。当一个程序终止的时候，某些已经无法访问的对象上的终结方法却根本没有被执行，这是完全有可能的。结论是：不应该依赖终结方法来更新重要的持久状态。例如，依赖终结方法来释放共享资源（比如数据库）上的永久锁，很容易让整个分布式系统垮掉。

        不要被System.gc和System.runFinalzatoin这两个方法所诱惑，他们确实增加了终结方法被执行的机会，但是它们并不保证终结方法一定会被执行。

        还有一点：使用终结方法有一个非常严重的（Severe）性能损失。

        那么，如果类的对象中封装的资源（例如文件或者线程）确实需要终止，应该怎么做才能不要编写终结方法呢？只需提供一个显示的终止方法，并要求该类的客户端在每个实例不再有用的时候调用这个方法。值得提及的一个细节是：该实例必须记录下自己是否已经被终止了：显示的终止方法必须在一个私有域中记录下“该对象已经不再有效”。如果这些方法是在对象已经终止之后被调用，其他的方法就必须检查这个域，并抛出IllegalStateException异常。

        显示终止方法的典型例子是InputStream、OutputStream和java.sql.Connection上的close方法。另一个例子是java.util.Timer上的cancel方法，它执行必要的状态改变，使得与Timer实例相关联的该线程温和地终止自己。java.awt中的例子还包括Graphics.dispose和Window.dispose。这些方法通常由于性能不好而不被人们关注。一个相关的方法是Image.flush，它会释放所有与Image实例相关联的资源，但是该实例仍然处于可用的状态，如果有必要的话，会重新分配资源。

        显示的终止方法通常与try-finally结构结合起来使用，以确保及时终止。在finally子句内部调用显示的终止方法，可以保证即使在使用对象的时候有异常抛出，该终止方法也会执行：

// try-finally block guarantees execution of termination method

Foo foo = new Foo(...);

try {

    // Do what must be done with foo

} finally {

   foo.terminate(); // Explicit termination method

}

        那么终结方法有什么好处呢？他们有两种合法用途。第一种用途是，当对象的所有者忘记调用前面段落中建议的显示终止方法时，终结方法可以充当“安全网（safety net）”。虽然这样做并不能保证终结方法会被及时地调用，但是在客户端无法通过电泳显示的终止方法来正常结束操作的情况下（希望这种情形尽可能的少发生），迟一点释放关键资源总比永远不释放要好。但是如果终结方法发现资源还未被终止，则应该在日志中记录一条警告，因为这表示客户端代码中的一个Bug，应该得到修复。

        显示终止方法模式的示例中所示的四个类（FileInputStream、FileOutputStream、Timer和Connection），都具有终止方法，当他们的终止方法未能被调用的调用下，这些中即额方法充当了安全网。

        终结方法的第二种合理用途与对象的本地对等体（native peer）有关。本地对等体是一个本地对象（native object），普通对象通过本地方法（native method）委托给一个本地对象。因为本地对等体不是一个普通对象，所以垃圾回收器不会知道它，当它的Java对等体被回收的时候，他不会被回收。在本地对等体并不拥有关键资源的前提下，终结方法正是执行这项任务最合适的工具。如果本地对等体拥有必须被即使终止的资源，那么该类就应该具有一个显示地终止方法，如前所述。终止方法应该完成所有必要的工作一遍释放关键的资源。终止方法可以是本地方法，或者他也可以调用本地方法。

        值得注意的很重要一点是，“终结方法链（finalizer chaining）”并不会被自动执行。如果类（不是Object）有终结方法，并且子类覆盖了终结方法，子类的终结方法就必须手工调用超类的终结方法。你应该在一个try块中终结子类，子类的终结方法就必须手工调用超类的终结方法。你应该在一个try块中终结子类，并在相应的finally块中调用超类的终结方法。这样做可以保证：即使子类的终结过程抛出异常，常磊的终结方法也会得到执行，反之亦然。

// Manual finalizer chaining

@Override 

protected void finalize() throws Throwable {

  try {

    ... // Finalize subclass state

 } finally {

   super.finalize();

 }

}

        如果子类实现者覆盖了超累的终结方法，但是忘了手工调用超类的终结方法（或者有意选择不调用超类的终结方法），那么超类的终结方法将永远也不会被调用到。要防范这样粗心大意或者恶意的子类是有可能的，代价就是为每个将被终结的对象创建一个附加的对象。不是把终结方法放在要求终结处理的类中，而是把终结方法方在一个匿名的类中，该匿名类的唯一用途就是终结它的外围实例（enclosing instance）。该匿名类的单个实例被称为终结方法守卫者（finalizer guardian），外围类的每个实例都会创建这样一个守卫者。外围实例在它的私有实例中保存着一个对其终结方法守卫者的唯一引用，因此终结方法守卫者与外围实例可以同时启动终结过程。当守卫者被终结的时候，它执行外围实例所期望的终结行为，就好像它的终结方法是外围对象上的一个方法一样：

// Finalizer Guardian idiom

public class Foo {

  // Sole purpose of this object is to finalize outer Foo object

  private final Object finalizerGuadian = new Object() {

@Override 

protected void finalize() throws Throwable {

... // Finalize outer Foo object

}

  };

}

        注意，共有类Foo并没有终结方法（除了它从Object继承了一个无关紧要的之外），所以子类的终结方法是否调用super.finalize并不重要。对于每一个带有终结方法的非final公有类，都应该考虑使用这种方法。

        总之，除非是作为安全网，或者是为了终止非关键的本地资源，否则请不要使用终结方法。在这些很少见的情况下，既然使用了终结方法，就要记住调用super.finalize。如果用终结方法作为安全网，要记得记录终结方法的非法用法。最后，如果需要把终结方法与公有的非final类关联起来，请考虑使用终结方法守卫者，以确保即使子类的终结方法未能调用super.finalize，该终结方法也会被执行。