为清除一个对象,那个对象的用户必须在希望进行清除的地点调用一个清除方法。这听起来似乎很容易做到,但却与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 1.1有时之所以会默认为跳过收尾工作,是由于它认为这样做的开销太大。不管用哪种方法强制进行垃圾收集,都可能注意到比没有额外收尾工作时较长的时间延迟。
闽公网安备 35060202000074号