Effective Java - 避免使用finalizer

Finalizers are unpredictable ,often dangerous ,and generally unnecessary.

在Java中，GC会自动回收不可达对象相关的空间，而不需要程序员做相关的工作。
对于非内存资源，我们通常使用try-finally语句块进行释放。

finalizer不保证立即执行。
从一个对象编程不可达状态到调用finalizer，这段时间是任意的。
即，对时间敏感的操作不能在finalizer中进行。

 

never do anything time-critical in finalizer.

比如对一些资源对象进行close，file descriptor是有限资源，不及时关闭的后果很严重。
(PS:话说AutoCloseable的author也是Josh Bloch。)

哪些finalizer会及时得到执行，这个问题主要依赖于GC算法。
但GC算法在不同的JVM中的表现或多或少会不一样(我做过的项目都是用Hotspot...)。
一个程序可能在开发时运行得不错，而换了个环境可能会无法正常运行。
(比如finalizer的优先级太低，一直没得到回收，回收速度跟不上创建速度。)

 

不仅不保证finalizer执行的及时性，而且也不保证finalizer执行的可能性。
finalizer有可能根本得不到执行。
比如，很多不可达对象的finalizer尚未得到执行，此时程序被终止。

Never depend on a finalizer to update critical persistent state.

也不要期待以下方法为finalizer的执行提供保障：

System.gc();



System.runFinalization();



Runtime.runFinalizersOnExit(true);



System.runFinalizersOnExit(true);

值得一提的是，如果未捕获的异常在finalizer中抛出，这个异常会被无视掉，而且连stack trace都不会打印出来。
另外，finalizer有非常严重的性能损耗，这种东西最好尽量避免。

如果某个对象封装的资源(比如文件或者线程)需要终止，此时也不要指望finalizer。
而是提供一个显示的close方法(explicit termination method)，并且加入一个记录资源可用状态的私有域。

那finalizer到底有什么意义?

• 当忘记调用close方法时，finalizer可以当作最后的防线(原话是safety net，即安全网)。
  比如FileInputStream的close方法和finalizer，当私有的FileDescriptor不为空并且也不属于java.lang.System#in时调用显示的close方法：

  /**
  
   * Ensures that the <code>close</code> method of this file input stream is
  
   * called when there are no more references to it.
  
   *
  
   * @exception  IOException  if an I/O error occurs.
  
   * @see        java.io.FileInputStream#close()
  
   */
  
  protected void finalize() throws IOException {
  
      if ((fd != null) &&  (fd != FileDescriptor.in)) {
  
  
  
          /*
  
           * Finalizer should not release the FileDescriptor if another
  
           * stream is still using it. If the user directly invokes
  
           * close() then the FileDescriptor is also released.
  
           */
  
          runningFinalize.set(Boolean.TRUE);
  
          try {
  
              close();
  
          } finally {
  
              runningFinalize.set(Boolean.FALSE);
  
          }
  
      }
  
  }

• 处理本地对等体(native peer)。
  之前没有太关注"本地对等体"这个词汇。
  本地对等体是一个native对象，普通对象通过本地方法委托给一个本地对象。
  GC无法回收本地对等体，当本地对等体的java对等体被回收的时候，本地对等体不会被处理。
  如果本地对等体不用有关键资源(critical resource)，finalizer可以胜任这项工作。

 

PS:对于本地对等体的解释，可以参考下面一段话：

一个AWT组件通常是一个包含了对等体接口类型引用的组件类。这个引用指向本地对等体实现。
java.awt.Label为例，它的对等体接口是LabelPeer。LabelPeer是平台无关的。
在不同平台上，AWT提供不同的对等体类来实现LabelPeer。在Windows上，对等体类是WlabelPeer，它调用JNI来实现label的功能。
这些JNI方法用C或C++编写。它们关联一个本地的label，真正的行为都在这里发生。
作为整体，AWT组件由AWT组件类和AWT对等体提供了一个全局公用的API给应用程序使用。
一个组件类和它的对等体接口是平台无关的。底层的对等体类和JNI代码是平台相关的。

(An AWT component is usually a component class which holds a reference with a peer interface type. This reference points to a native peer implementation.
Take java.awt.Label for example, its peer interface is LabelPeer.
LabelPeer is platform independent. On every platform, AWT provides different peer class which implements LabelPeer. On Windows, the peer class is WlabelPeer, which implement label functionalities by JNI calls.
These JNI methods are coded in C or C++. They do the actual work, interacting with a native label.
Let's look at the figure.
You can see that AWT components provide a universal public API to the application by AWT component class and AWT peers. A component class and its peer interface are identical across platform. Those underlying peer classes and JNI codes are different. )

另外，提到了finalizer chaining。 子类构造器会自动调用父类构造器，于是可能会想象子类finalizer自动调用父类finalizer。 如果子类复写了父类的finalizer，子类必须手动调用父类的finalier。