07-避免使用终结方法
01 - 终结方法（finalizer）通常是不可预测的，也是危险的，一般情况下是不必要的。使用终结方法会导致行为不稳定、降低性能，以及可移植性问题。当然，终结方法也有其可用之处。
02 - 在Java中，当一个对象变得不可到达的时候，垃圾回收器会与该对象相关联的存储空间，并不需要程序员做专门的工作。C++的析构器也可以被用来回收其他的非内存资源。而在Java中，一般用try-finally块来完成类似的工作。
03 - 终结方法的缺点在于不能保证会被及时地执行。从一个对象变得不可到达的开始，到它的终结方法被执行，所花费的时间是任意长的。这意味着，注重时间(time-critical)的任务不应该由终结方法来完成。例如，用终结方法来关闭已经打开的文件，这是严重错误，因为打开文件的描述符是一种很有限的资源。由于Jvm会延迟执行终结方法，所以大量的文件会保留在打开状态，当一个程序再不能打卡文件的时候，它可能会运行失败。
04 - 及时地执行终结方法正是垃圾回收算法的一个主要功能，这种算法在不同的Jvm实现中会大相径庭。如果程序依赖于终结方法被执行的时间点，那么这个程序的行为在不同的Jvm中运行的表现可能就会截然不同。一个程序在测试用的Jvm平台上运行得非常好，而在最重要的客户的Jvm平台上却根本无法运行，这是完全有可能的。
05 - 延迟终结过程并不只是一个理论问题。在很少见的情况下，为类提供终结方法，可能会随意地延迟其实例的回收过程。例如，调试一个长期运行的GUI应用程序，该应用程序莫名其妙地出现OOM错误而死掉。分析表明，该应用程序死掉的时候，其终结方法队列中有数千个图形对象正在等待被终结和回收。遗憾的是，终结方法线程的优先级比该应用程序的其他线程要低得多，所以图形对象的终结速度达不到它们进入队列的速度。Java语言规范并不保证哪个线程执行终结方法，所以，除了不使用终结方法之外，并没有很轻便的办法能够避免这样的问题。
06 - Java语言规范不仅不保证终结方法会被及时执行，而且根本就不保证它们会执行。当一个程序终止的时候，某些已经无法访问的对象上的=终结方法却根本没有被执行，这是完全有肯能的。结论是：不应该依赖终结方法来更新重要的持久状态。例如，依赖终结方法来释放共享资源上的永久锁，很容易让整个分布式系统垮掉。
07 - 不要被System.gc和System.runFinalization这两个方法所迷惑，它们确实增加了终结方法被执行的机会，但是它们并不保证终结方法一定会被执行。唯一声称保证终结方法被执行的方法时System.runFinalizersOnExit，以及它臭名昭著的孪生兄弟Runtime.runFinalizersOnExit。这两个方法都有致命的缺陷，已经被废弃了。
08 - 当你并不确定是否应该避免使用终结方法的时候，这里有一种值得考虑的情形：如果未捕获的异常在终结过程中被抛出来，那么这种异常可以被忽略，并且该对象的终结过程也会终止。未被捕获的异常会使对象处于破坏的状态，如果另一个线程企图使用这种破坏的对象，则可能发生任何不确定的行为。正常情况下，未被捕获的异常将会使线程终止，并打印出栈轨迹，但是，如果异常发生在终结方法之中，则不会如此，甚至连警告也不会打印出来。
09 - 如果类的对象中封装的资源确实需要终止，只需要提供一个显式的终止方法，并要求改类的客户端在每个实例不再有的时候调用这个方法。值得提及的是，该实例必须记录下自己师傅已经被终止了：显式的终止方法必须在一个私有域中记录下“该对象已经不再有效”。如果这些方法是在对象已经终止之后被调用，其他的方法就必须检查这个域，并抛出IllegalStateException异常，
010 - 显式终止方法的典型例子是InputStream、OutputStream和java.sql.Connection上的close方法。另一个例子是java.util.Timer上的cancel方法，它执行必要的状态改变，使得与Timer实例相关联的该线程温和地终止自己。java.awt中的例子还包括Graphics.dispose和Windwo.dispose。这些方法通常由于性能不好而不被人们关注。一个相关的方法时Image.flush，它会释放所有与Image实例相关联的资源，但是该实例仍然处于可用状态，如果有必要的话，会重新分配资源。
011 - 显式的终止方法通常与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
}
012 - 终结方法有两种合法的用途。第一种用途是，当对象的所有者忘记调用前面段落中建议的显式终止方法时，终结方法可以充当“安全网（safety net）”。虽然这样做并不能保证终结方法会被及时调用，但是在客户端无法通过调用显式的终结方法来正常结束操作的情况下，迟一点释放关键资源总比永远不释放要好。但是如果终结方法发现资源还未被终止，则应该在日志中记录一条警告因为这表示客户端代码中的一个bug，应该得到修复。（这种额外的保护是否值得你付出这份额外的代价）
013 - 终结方法的第二种合理用途与对象的本地对等体（native peer）有关。本地对等体是一个本地对象（native object），普通对象通过本地方法（native method）委托给一个本地对象，因为本地对等体不是一个普通对象，所以垃圾回收器不会知道它，当它的Java对等体被回收的时候，它不会被回收。在本地对等体并不拥有关键资源的前提下，终结方法正是执行这项任务最合适的工具。如果本地对等体拥有必须被及时终止的资源，那么该类就应该具有一个显式的终止方法。
014 - 值得注意的很重要的一点是，终结方法链（finalizer chainning）并不会被自动执行。如果类有终结方法，并且子类覆盖了终结方法，子类的终结方法就必须手工调用父类的终结方法。这样做可以保证：即使子类的终结过程抛出异常，超类的终结方法也会得到执行。反之亦然。
//Manual finalizer chainning
@override
protected void finalizer()throws Throwable
{
try
{
//Finalize subclass state
}
finally
{
super.finalize();
}
}
015 - 不是把终结方法放在要求终结的类中，而是放在一个匿名类中，该匿名类的唯一用途就是处理它的外围实例。该匿名类的单个实例被称为终结方法守卫者，外围类的每个实例都会创建这样一个守卫者。外围实例在它的私有实例域中保存着一个对其终结方法守卫者的唯一的引用，因此终结方法守卫者与外围实例可以同时启动终结过程。当守卫者被终结时，它执行外围实例所期望的终结行为，就好像它的终结方法时外围对象上的一个方法一样：
//Finalizer Grardian idiom
public class Foo
{
//So 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
}
};
//Reminder omitted
}
016 - 公有类Foo并没有终结方法，所以子类的终结方法是否调用super.finalize并不重要。对于每一个带有终结方法的非final公有类，都应该考虑使用这种方法。
017 - 总而言之，除非是作为安全网，或者是为了终止非关键的本地资源，否则不使用终结方法。在这些很少见的情况下，既然使用了终结方法，就要记住调用super.finalize。如果需要把终结方法与公有非final类关联起来，考虑使用终结方法守卫者，以确保即使子类的终结方法未能被调用super.finalize，该总结方法也会被执行。
网友评论