第7条：避免使用终结方法

术语：

本地对等体(native peer)：本地对等体是一个本地对象，普通对象通过本地方法委托给一个本地对象。    

        终结方法(finalizer)通常是不可预测的，也是很危险的，一般情况下也是不必要的。使用终结方法会导致行为不稳定、降低性能，以及可移植性的问题。虽然终结方法也有可用之处，但是还是应该避免使用它。

        终结方法不等同C++中的析构器，在C++中析构器是回收一个对象资源的常规方法，是构造器对应的必需物。但是在JAVA中，当一个对象变得不可到达 的时候，垃圾回收器会回收与该对象相关联的存储空间，并不需要程序员专门做这项工作，C++人析构器也可以被用来回收其他的非内存资源，而在JAVA中，一般用try-finally来完成类似的工作。

       终结方法的缺点在于不能保证被及时的执行，从一个对象变成不可到达的状态开始，到它的终结方法被执行，所花费的时间是任意长的，所以注重时间的任务不应该由终结方法来完成，比如说用终结方法来关闭已打开的文件，由于JVM会延迟执行终结方法，所以大量的文件会保留在打开状态，当一个程序再不能打开新文件的时候，可能会引起当前运行失败。同时，不同的JVM在执行终结方法的时候的表现大不相同，如果程序依赖于终结方法被执行的时间点，那么这个程序的行为在不同的JVM中运行的表现会大不相同，一个程序你在测试用的JVM上运行正常可以在顾客的JVM平台上根本无法运行。

       在很少见的情况下，为类提供终结方法，可能会随意地延迟其实例的回收过程。因为终结方法线程的优先级要比其他的线程低的多，所以长期运行的程序有可能出现对象进入队列的速度比他们终结的速度要快，最终会导致内存泄露。JAVA语言规范并不保证哪个线程将会执行终结方法，所以，除了不使用终结方法之外，没有什么好的方法可以避免这样的问题。JAVA的语言规范不仅不保证终结方法被及时执行，而且根本就不保证它们会被执行。当一个程序终结的时候，某些已经无法访问的对象上的终结方法却根本没有被执行，这是完全可能的。这里得到的结论就是：不应该依赖终结方法来更新重要的持久状态。例如，依赖终结方法来释放共享资源（比如，数据库）上的永久锁，很容易让整个分布式系统跨掉。

        如果并不确定是否应该避免使用终结方法的时候，这里还有一种值得考虑的情形，如果未被捕获的异常在终结过程中被抛出，那么这种异常可以被忽略，并且对该对象的终结过程也会终止。未被捕获的异常会使对象处于被破坏的状态，如果另一个线程企图使用这种被破坏的状态，那么则可能发生任何不确定的行为。终结方法还会造成非常严重的性能损失，用终结方法创建和销毁对象会比正常方法要慢很多。

        基于以上的原因，如果类中的对象封闭的资源确实需要被终止，那么应该提供一个显示的终止方法，并且要求客户端在每个实例不再有用的时候调用这个方法，值得提及的一个细节是，该实例必须要记录下自己是否已经被终止 了：显式的终止方法必须在一个私有域中记录下“该对象已经不再有效”。如果这些方法是在对象已经被终止之后被调用，其他的方法就必须检查这个域，并抛出IllegalStateException。显式终止的典型例子是InputStream, OutputStream和java.util.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
}

        虽然终结方法有如上一些缺点，但是他们也有两种合法的用途。

        第一种是当对象的所有者忘记调用前面建议的显式终结方法的时候，终结方法可以充当安全网，虽然这样做并不能保证终结方法能被及时的调用，但是在客户端无法通过调用显式的终结方法来正常结束操作的情况下，晚一点释放总比不释放的好。但是如果终结方法发现资源还未被终止，应该在日志中记录一条警告，因为这表明客户端代码中的一个bug，应该得到修复。在使用这种方法之前，一定要衡量一下这样做是否值得。显式终结方法的模式示例中的所有四个类FileInputStream, FileOutputStream, Timer和Connection，都具有终结方法，当它们的终结方法未能被调用的情况下，这些终结方法充当了安全网。也就是说提供了两套机制，一种是显式终结，交由客户来调用，如果客户未能调用安全的显式终止，则这些终结方法将充当安全网。

        第二种合理用途与对象的本地对等体(natvie peer)有关。因为本地对等体不是一个普通的对象，所以垃圾回收器并不知道它，当它的java对等体被回收的时候，它却不会被回收掉。在本地对等体并不拥有关键资源的前提下，终结方法正是执行这项任务的最合适工具，如果本地对等体拥有必须被及时终止的资源，那么此类就应该具有一个显式的终止方法，终止方法应该完成所有必要的工作以便释放掉关键的资源，终止方法既可以是本地方法，也可以调用本地方法。

        有一个需要注意的重要点，“终结方法链”并不会被自动执行，如果类(非Object)有终结方法，并且子类覆盖了终结方法，那么子类 的终结方法就必须 手工调用超类的终结方法。应该在一个try块中终结子类，并且在相应的finally块中调用超类的终结方法。这样就可以保证：即使子类的终结过程抛出了异常，超类的终结方法也会被执行，还记得吧，上面说过如果在终结过程中抛出异常，则不会抛出异常，这种方法可以克服这样的缺点。

// Manual finalizer chaining
@Override
protected void finalize() throws Throwable {
	try {
		// Finalize subclass state
	} finally {
		super.finalize();
	}
}

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

// Finalizer Guardian idiom
public class Foo {
	// Sole purpose of this object is to finalize outer Foo object
	private final Object finalizerGuardian = new Object() {
		@Override
		protected void finalize() throws Throwable {
			// Finalize outer Foo object
		}
	};
	// Remainder omitted
}

        上面这个例子中，类Foo并没有终结方法（事实上，从Object继承了一个），所以子类的终结方法是否调用super.finalize并不重要。一般情况下，调用了终结方法，就要记得调用super.finalize。如果终结方法作为安全网，要记得记录终结方法的非法用法 ，最后如果需要把终结方法与仅有的非final类关联起来，请考虑使用终结方法守卫者，以确保即使子类的终结方法未能调用super.finalize。该终结方法也会被执行。