Question

为清除一个对象，那个对象的用户必须在希望进行清除的地点调用一个清除方法。这听起来似乎很容易做到，但却与 C++“破坏器”的概念稍有抵触。在 C++中，所有对象都会破坏（清除）。或者换句话说，所有对象都“应该”破坏。若将 C++对象创建成一个本地对象，比如在堆栈中创建（在 Java 中是不可能的），那么清除或破坏工作就会在“结束花括号”所代表的、创建这个对象的作用域的末尾进行。若对象是用 new 创建的（类似于 Java），那么当程序员调用 C++的 delete 命令时（Java 没有这个命令），就会调用相应的破坏器。若程序员忘记了，那么永远不会调用破坏器，我们最终得到的将是一个内存“漏洞”，另外还包括对象的其他部分永远不会得到清除。

相反，Java 不允许我们创建本地（局部）对象——无论如何都要使用 new。但在 Java 中，没有“delete”命令来释放对象，因为垃圾收集器会帮助我们自动释放存储空间。所以如果站在比较简化的立场，我们可以说正是由于存在垃圾收集机制，所以 Java 没有破坏器。然而，随着以后学习的深入，就会知道垃圾收集器的存在并不能完全消除对破坏器的需要，或者说不能消除对破坏器代表的那种机制的需要（而且绝对不能直接调用 finalize()，所以应尽量避免用它）。若希望执行除释放存储空间之外的其他某种形式的清除工作，仍然必须调用 Java 中的一个方法。它等价于 C++的破坏器，只是没后者方便。

finalize() 最有用处的地方之一是观察垃圾收集的过程。下面这个例子向大家展示了垃圾收集所经历的过程，并对前面的陈述进行了总结。

//: Garbage.java
// Demonstration of the garbage
// collector and finalization

class Chair {
  static boolean gcrun = false;
  static boolean f = false;
  static int created = 0;
  static int finalized = 0;
  int i;
  Chair() {
    i = ++created;
    if(created == 47) 
      System.out.println("Created 47");
  }
  protected void finalize() {
    if(!gcrun) {
      gcrun = true;
      System.out.println(
        "Beginning to finalize after " +
        created + " Chairs have been created");
    }
    if(i == 47) {
      System.out.println(
        "Finalizing Chair #47, " +
        "Setting flag to stop Chair creation");
      f = true;
    }
    finalized++;
    if(finalized >= created)
      System.out.println(
        "All " + finalized + " finalized");
  }
}

public class Garbage {
  public static void main(String[] args) {
    if(args.length == 0) {
      System.err.println("Usage: \n" +
        "java Garbage before\n  or:\n" +
        "java Garbage after");
      return;
    }
    while(!Chair.f) {
      new Chair();
      new String("To take up space");
    }
    System.out.println(
      "After all Chairs have been created:\n" +
      "total created = " + Chair.created +
      ", total finalized = " + Chair.finalized);
    if(args[0].equals("before")) {
      System.out.println("gc():");
      System.gc();
      System.out.println("runFinalization():");
      System.runFinalization();
    }
    System.out.println("bye!");
    if(args[0].equals("after"))
      System.runFinalizersOnExit(true);
  }
} ///:~

上面这个程序创建了许多 Chair 对象，而且在垃圾收集器开始运行后的某些时候，程序会停止创建 Chair。由于垃圾收集器可能在任何时间运行，所以我们不能准确知道它在何时启动。因此，程序用一个名为 gcrun 的标记来指出垃圾收集器是否已经开始运行。利用第二个标记 f，Chair 可告诉 main() 它应停止对象的生成。这两个标记都是在 finalize() 内部设置的，它调用于垃圾收集期间。

另两个 static 变量——created 以及 finalized——分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作的对象数量。最后，每个 Chair 都有它自己的（非 static）int i，所以能跟踪了解它具体的编号是多少。编号为 47 的 Chair 进行完收尾工作后，标记会设为 true，最终结束 Chair 对象的创建过程。

所有这些都在 main() 的内部进行——在下面这个循环里：

while(!Chair.f) {

new Chair();

new String("To take up space");

}

大家可能会疑惑这个循环什么时候会停下来，因为内部没有任何改变 Chair.f 值的语句。然而，finalize() 进程会改变这个值，直至最终对编号 47 的对象进行收尾处理。

每次循环过程中创建的 String 对象只是属于额外的垃圾，用于吸引垃圾收集器——一旦垃圾收集器对可用内存的容量感到“紧张不安”，就会开始关注它。

运行这个程序的时候，提供了一个命令行自变量“before”或者“after”。其中，“before”自变量会调用 System.gc() 方法（强制执行垃圾收集器），同时还会调用 System.runFinalization() 方法，以便进行收尾工作。这些方法都可在 Java 1.0 中使用，但通过使用“after”自变量而调用的 runFinalizersOnExit() 方法却只有 Java 1.1 及后续版本提供了对它的支持（注释③）。注意可在程序执行的任何时候调用这个方法，而且收尾程序的执行与垃圾收集器是否运行是无关的。

③：不幸的是，Java 1.0 采用的垃圾收集器方案永远不能正确地调用 finalize()。因此，finalize() 方法（特别是那些用于关闭文件的）事实上经常都不会得到调用。现在有些文章声称所有收尾模块都会在程序退出的时候得到调用——即使到程序中止的时候，垃圾收集器仍未针对那些对象采取行动。这并不是真实的情况，所以我们根本不能指望 finalize() 能为所有对象而调用。特别地，finalize() 在 Java 1.0 里几乎毫无用处。

前面的程序向我们揭示出：在 Java 1.1 中，收尾模块肯定会运行这一许诺已成为现实——但前提是我们明确地强制它采取这一操作。若使用一个不是“before”或“after”的自变量（如“none”），那么两个收尾工作都不会进行，而且我们会得到象下面这样的输出：

Created 47

Created 47
Beginning to finalize after 8694 Chairs have been created
Finalizing Chair #47, Setting flag to stop Chair creation
After all Chairs have been created:
total created = 9834, total finalized = 108
bye!

因此，到程序结束的时候，并非所有收尾模块都会得到调用（注释④）。为强制进行收尾工作，可先调用 System.gc()，再调用 System.runFinalization()。这样可清除到目前为止没有使用的所有对象。这样做一个稍显奇怪的地方是在调用 runFinalization() 之前调用 gc()，这看起来似乎与 Sun 公司的文档说明有些抵触，它宣称首先运行收尾模块，再释放存储空间。然而，若在这里首先调用 runFinalization()，再调用 gc()，收尾模块根本不会执行。

④：到你读到本书时，有些 Java 虚拟机（JVM）可能已开始表现出不同的行为。

针对所有对象，Java 1.1 有时之所以会默认为跳过收尾工作，是由于它认为这样做的开销太大。不管用哪种方法强制进行垃圾收集，都可能注意到比没有额外收尾工作时较长的时间延迟。