Java编程思想第4版[中文版](PDF格式)-第37部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
象占据的内存。现在考虑一种非常特殊且不多见的情况。假定我们的对象分配了一个“特殊”内存区域，没
有使用 new。垃圾收集器只知道释放那些由new 分配的内存，所以不知道如何释放对象的“特殊”内存。为
解决这个问题，Java 提供了一个名为finalize（）的方法，可为我们的类定义它。在理想情况下，它的工作原
理应该是这样的：一旦垃圾收集器准备好释放对象占用的存储空间，它首先调用 finalize（），而且只有在下
一次垃圾收集过程中，才会真正回收对象的内存。所以如果使用finalize（），就可以在垃圾收集期间进行一
些重要的清除或清扫工作。
但也是一个潜在的编程陷阱，因为有些程序员（特别是在 C＋＋开发背景的）刚开始可能会错误认为它就是在
C＋＋中为“破坏器”（Destructor）使用的finalize（）——破坏（清除）一个对象的时候，肯定会调用这个
函数。但在这里有必要区分一下C＋＋和 Java 的区别，因为C＋＋的对象肯定会被清除（排开编程错误的因
素），而Java 对象并非肯定能作为垃圾被“收集”去。或者换句话说：
垃圾收集并不等于“破坏”！
若能时刻牢记这一点，踩到陷阱的可能性就会大大减少。它意味着在我们不再需要一个对象之前，有些行动
是必须采取的，而且必须由自己来采取这些行动。Java 并未提供“破坏器”或者类似的概念，所以必须创建
一个原始的方法，用它来进行这种清除。例如，假设在对象创建过程中，它会将自己描绘到屏幕上。如果不
从屏幕明确删除它的图像，那么它可能永远都不会被清除。若在finalize（）里置入某种删除机制，那么假设
对象被当作垃圾收掉了，图像首先会将自身从屏幕上移去。但若未被收掉，图像就会保留下来。所以要记住
的第二个重点是：
我们的对象可能不会当作垃圾被收掉！
有时可能发现一个对象的存储空间永远都不会释放，因为自己的程序永远都接近于用光空间的临界点。若程
序执行结束，而且垃圾收集器一直都没有释放我们创建的任何对象的存储空间，则随着程序的退出，那些资
源会返回给操作系统。这是一件好事情，因为垃圾收集本身也要消耗一些开销。如永远都不用它，那么永远
也不用支出这部分开销。
4。3。1 finalize（） 用途何在
此时，大家可能已相信了自己应该将finalize（）作为一种常规用途的清除方法使用。它有什么好处呢？
要记住的第三个重点是：
垃圾收集只跟内存有关！
也就是说，垃圾收集器存在的唯一原因是为了回收程序不再使用的内存。所以对于与垃圾收集有关的任何活
动来说，其中最值得注意的是finalize（）方法，它们也必须同内存以及它的回收有关。
但这是否意味着假如对象包含了其他对象，finalize（）就应该明确释放那些对象呢？答案是否定的——垃圾
收集器会负责释放所有对象占据的内存，无论这些对象是如何创建的。它将对finalize（）的需求限制到特殊
的情况。在这种情况下，我们的对象可采用与创建对象时不同的方法分配一些存储空间。但大家或许会注意
到，Java 中的所有东西都是对象，所以这到底是怎么一回事呢？
之所以要使用finalize（），看起来似乎是由于有时需要采取与Java 的普通方法不同的一种方法，通过分配
内存来做一些具有C 风格的事情。这主要可以通过“固有方法”来进行，它是从Java 里调用非 Java 方法的
一种方式（固有方法的问题在附录 A 讨论）。C 和 C＋＋是目前唯一获得固有方法支持的语言。但由于它们能调
用通过其他语言编写的子程序，所以能够有效地调用任何东西。在非 Java 代码内部，也许能调用 C 的
malloc（）系列函数，用它分配存储空间。而且除非调用了free（），否则存储空间不会得到释放，从而造成内
存“漏洞”的出现。当然，free（）是一个C 和C＋＋函数，所以我们需要在 finalize（）内部的一个固有方法中
105
…………………………………………………………Page 107……………………………………………………………
调用它。
读完上述文字后，大家或许已弄清楚了自己不必过多地使用finalize（）。这个思想是正确的；它并不是进行
普通清除工作的理想场所。那么，普通的清除工作应在何处进行呢？
4。3。2 必须执行清除
为清除一个对象，那个对象的用户必须在希望进行清除的地点调用一个清除方法。这听起来似乎很容易做
到，但却与 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（
106
…………………………………………………………Page 108……………………………………………………………
〃All 〃 ＋ finalized ＋ 〃 finalized〃）；
｝
｝
public class Garbage ｛
public static void main（String＇＇ args） ｛
if（args。length == 0） ｛
System。err。println（〃Usage： n〃 ＋
〃java Garbage beforen 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（）方法，以便进行收尾
107
…………………………………………………………Page 109……………………………………………………………
工作。这些方法都可在 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
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 有时之所以会默认为跳过收尾工作，是由于它认为这样做的开销太大。不管用哪种
方法强制进行垃圾收集，都可能注意到比没有额外收尾工作时较长的时间延迟。
4。4 成员初始化
Java 尽自己的全力保证所有变量都能在使用前得到正确的初始化。若被定义成相对于一个方法的“局�
