“随着计算机的进步, ‘不安全’的程序设计已成为造成编程代价高昂的罪魁祸首之一。”

“初始化”和“清除”是这些安全问题的其中两个。许多C程序的错误都是由于程序员忘记初始化一个变量造成的。对于现成的库, 若用户不知道如何初始化库的一个组件, 就往往会出现这一类的错误。清除是另一个特殊的问题, 因为用完一个元素后, 由于不再关心, 所以很容易把它忘记。这样一来, 那个元素占用的资源会一直保留下去, 极易产生资源（主要是内存）用尽的后果。
C++为我们引入了“构建器”的概念。这是一种特殊的方法, 在一个对象创建之后自动调用。Java也沿用了这个概念, 但新增了自己的“垃圾收集器”, 能在资源不再需要的时候自动释放它们。本章将讨论初始化和清除的问题, 以及Java如何提供它们的支持。

4.1 用构建器自动初始化
对于方法的创建, 可将其想象成为自己写的每个类都调用一次initialize()。这个名字提醒我们在使用对象之前, 应首先进行这样的调用。但不幸的是, 这也意味着用户必须记住调用方法。在Java中, 由于提供了名为“构建器”的一种特殊方法, 所以类的设计者可担保每个对象都会得到正确的初始化。若某个类有一个构建器, 那么在创建对象时, Java会自动调用那个构建器——甚至在用户毫不知觉的情况下。所以说这是可以担保的！
接着的一个问题是如何命名这个方法。存在两方面的问题。第一个是我们使用的任何名字都可能与打算为某个类成员使用的名字冲突。第二是由于编译器的责任是调用构建器, 所以它必须知道要调用是哪个方法。C++采取的方案看来是最简单的, 且更有逻辑性, 所以也在Java里得到了应用：构建器的名字与类名相同。这样一来, 可保证象这样的一个方法会在初始化期间自动调用。
下面是带有构建器的一个简单的类（若执行这个程序有问题, 请参考第3章的“赋值”小节）。

148-149页程序

现在, 一旦创建一个对象：
new Rock();
就会分配相应的存储空间, 并调用构建器。这样可保证在我们经手之前, 对象得到正确的初始化。
请注意所有方法首字母小写的编码规则并不适用于构建器。这是由于构建器的名字必须与类名完全相同！
和其他任何方法一样, 构建器也能使用自变量, 以便我们指定对象的具体创建方式。可非常方便地改动上述例子, 以便构建器使用自己的自变量。如下所示：

149页中程序

利用构建器的自变量, 我们可为一个对象的初始化设定相应的参数。举个例子来说, 假设类Tree有一个构建器, 它用一个整数自变量标记树的高度, 那么就可以象下面这样创建一个Tree对象：

tree t = new Tree(12); // 12英尺高的树

若Tree(int)是我们唯一的构建器, 那么编译器不会允许我们以其他任何方式创建一个Tree对象。
构建器有助于消除大量涉及类的问题, 并使代码更易阅读。例如在前述的代码段中, 我们并未看到对initialize()方法的明确调用——那些方法在概念上独立于定义内容。在Java中, 定义和初始化属于统一的概念——两者缺一不可。
构建器属于一种较特殊的方法类型, 因为它没有返回值。这与void返回值存在着明显的区别。对于void返回值, 尽管方法本身不会自动返回什么, 但仍然可以让它返回另一些东西。构建器则不同, 它不仅什么也不会自动返回, 而且根本不能有任何选择。若存在一个返回值, 而且假设我们可以自行选择返回内容, 那么编译器多少要知道如何对那个返回值作什么样的处理。

4.2 方法过载
在任何程序设计语言中, 一项重要的特性就是名字的运用。我们创建一个对象时, 会分配到一个保存区域的名字。方法名代表的是一种具体的行动。通过用名字描述自己的系统, 可使自己的程序更易人们理解和修改。它非常象写散文——目的是与读者沟通。
我们用名字引用或描述所有对象与方法。若名字选得好, 可使自己及其他人更易理解自己的代码。
将人类语言中存在细致差别的概念“映射”到一种程序设计语言中时, 会出现一些特殊的问题。在日常生活中, 我们用相同的词表达多种不同的含义——即词的“过载”。我们说“洗衬衫”、“洗车”以及“洗狗”。但若强制象下面这样说, 就显得很愚蠢：“衬衫洗 衬衫”、“车洗 车”以及“狗洗 狗”。这是由于听众根本不需要对执行的行动作任何明确的区分。人类的大多数语言都具有很强的“冗余”性, 所以即使漏掉了几个词, 仍然可以推断出含义。我们不需要独一无二的标识符——可从具体的语境中推论出含义。
大多数程序设计语言（特别是C）要求我们为每个函数都设定一个独一无二的标识符。所以绝对不能用一个名为print()的函数来显示整数, 再用另一个print()显示浮点数——每个函数都要求具备唯一的名字。
在Java里, 另一项因素强迫方法名出现过载情况：构建器。由于构建器的名字由类名决定, 所以只能有一个构建器名称。但假若我们想用多种方式创建一个对象呢？例如, 假设我们想创建一个类, 令其用标准方式进行初始化, 另外从文件里读取信息来初始化。此时, 我们需要两个构建器, 一个没有自变量（默认构建器）, 另一个将字串作为自变量——用于初始化对象的那个文件的名字。由于都是构建器, 所以它们必须有相同的名字, 亦即类名。所以为了让相同的方法名伴随不同的自变量类型使用, “方法过载”是非常关键的一项措施。同时, 尽管方法过载是构建器必需的, 但它亦可应用于其他任何方法, 且用法非常方便。
在下面这个例子里, 我们向大家同时展示了过载构建器和过载的原始方法：

151-152页程序

Tree既可创建成一颗种子, 不含任何自变量；亦可创建成生长在苗圃中的植物。为支持这种创建, 共使用了两个构建器, 一个没有自变量（我们把没有自变量的构建器称作“默认构建器”, 注释①）, 另一个采用现成的高度。

①：在Sun公司出版的一些Java资料中, 用简陋但很说明问题的词语称呼这类构建器——“无参数构建器”（no-arg constructors）。但“默认构建器”这个称呼已使用了许多年, 所以我选择了它。

我们也有可能希望通过多种途径调用info()方法。例如, 假设我们有一条额外的消息想显示出来, 就使用String自变量；而假设没有其他话可说, 就不使用。由于为显然相同的概念赋予了两个独立的名字, 所以看起来可能有些古怪。幸运的是, 方法过载允许我们为两者使用相同的名字。

4.2.1 区分过载方法
若方法有同样的名字, Java怎样知道我们指的哪一个方法呢？这里有一个简单的规则：每个过载的方法都必须采取独一无二的自变量类型列表。
若稍微思考几秒钟, 就会想到这样一个问题：除根据自变量的类型, 程序员如何区分两个同名方法的差异呢？
即使自变量的顺序也足够我们区分两个方法（尽管我们通常不愿意采用这种方法, 因为它会产生难以维护的代码）：

152-153页程序

两个print()方法有完全一致的自变量, 但顺序不同, 可据此区分它们。

4.2.2 主类型的过载
主（数据）类型能从一个“较小”的类型自动转变成一个“较大”的类型。涉及过载问题时, 这会稍微造成一些混乱。下面这个例子揭示了将主类型传递给过载的方法时发生的情况：

153-155页程序

若观察这个程序的输出, 就会发现常数值5被当作一个int值处理。所以假若可以使用一个过载的方法, 就能获取它使用的int值。在其他所有情况下, 若我们的数据类型“小于”方法中使用的自变量, 就会对那种数据类型进行“转型”处理。char获得的效果稍有些不同, 这是由于假期它没有发现一个准确的char匹配, 就会转型为int。
若我们的自变量“大于”过载方法期望的自变量, 这时又会出现什么情况呢？对前述程序的一个修改揭示出了答案：

155-157页程序

在这里, 方法采用了容量更小、范围更窄的主类型值。若我们的自变量范围比它宽, 就必须用括号中的类型名将其转为适当的类型。如果不这样做, 编译器会报告出错。
大家可注意到这是一种“缩小转换”。也就是说, 在造型或转型过程中可能丢失一些信息。这正是编译器强迫我们明确定义的原因——我们需明确表达想要转型的愿望。

4.2.3 返回值过载
我们很易对下面这些问题感到迷惑：为什么只有类名和方法自变量列出？为什么不根据返回值对方法加以区分？比如对下面这两个方法来说, 虽然它们有同样的名字和自变量, 但其实是很容易区分的：
void f() {}
int f() {}
若编译器可根据上下文（语境）明确判断出含义, 比如在int x=f()中, 那么这样做完全没有问题。然而, 我们也可能调用一个方法, 同时忽略返回值；我们通常把这称为“为它的副作用去调用一个方法”, 因为我们关心的不是返回值, 而是方法调用的其他效果。所以假如我们象下面这样调用方法：
f();
Java怎样判断f()的具体调用方式呢？而且别人如何识别并理解代码呢？由于存在这一类的问题, 所以不能根据返回值类型来区分过载的方法。

4.2.4 默认构建器
正如早先指出的那样, 默认构建器是没有自变量的。它们的作用是创建一个“空对象”。若创建一个没有构建器的类, 则编译程序会帮我们自动创建一个默认构建器。例如：

158页上程序

对于下面这一行：
new Bird();
它的作用是新建一个对象, 并调用默认构建器——即使尚未明确定义一个象这样的构建器。若没有它, 就没有方法可以调用, 无法构建我们的对象。然而, 如果已经定义了一个构建器（无论是否有自变量）, 编译程序都不会帮我们自动合成一个：

class Bush {
Bush(int i) {}
Bush(double d) {}
}

现在, 假若使用下述代码：
new Bush();
编译程序就会报告自己找不到一个相符的构建器。就好象我们没有设置任何构建器, 编译程序会说：“你看来似乎需要一个构建器, 所以让我们给你制造一个吧。”但假如我们写了一个构建器, 编译程序就会说：“啊, 你已写了一个构建器, 所以我知道你想干什么；如果你不放置一个默认的, 是由于你打算省略它。”

4.2.5 this关键字
如果有两个同类型的对象, 分别叫作a和b, 那么您也许不知道如何为这两个对象同时调用一个f()方法：

class Banana { void f(int i) { /* ... */ } }
Banana a = new Banana(), b = new Banana();
a.f(1);
b.f(2);

若只有一个名叫f()的方法, 它怎样才能知道自己是为a还是为b调用的呢？
为了能用简便的、面向对象的语法来书写代码——亦即“将消息发给对象”, 编译器为我们完成了一些幕后工作。其中的秘密就是第一个自变量传递给方法f(), 而且那个自变量是准备操作的那个对象的句柄。所以前述的两个方法调用就变成了下面这样的形式：

Banana.f(a,1);
Banana.f(b,2);

这是内部的表达形式, 我们并不能这样书写表达式, 并试图让编译器接受它。但是, 通过它可理解幕后到底发生了什么事情。
假定我们在一个方法的内部, 并希望获得当前对象的句柄。由于那个句柄是由编译器“秘密”传递的, 所以没有标识符可用。然而, 针对这一目的有个专用的关键字：this。this关键字（注意只能在方法内部使用）可为已调用了其方法的那个对象生成相应的句柄。可象对待其他任何对象句柄一样对待这个句柄。但要注意, 假若准备从自己某个类的另一个方法内部调用一个类方法, 就不必使用this。只需简单地调用那个方法即可。当前的this句柄会自动应用于其他方法。所以我们能使用下面这样的代码：

class Apricot {
void pick() { /* ... */ }
void pit() { pick(); /* ... */ }
}

在pit()内部, 我们可以说this.pick(), 但事实上无此必要。编译器能帮我们自动完成。this关键字只能用于那些特殊的类——需明确使用当前对象的句柄。例如, 假若您希望将句柄返回给当前对象, 那么它经常在return语句中使用。

160页上程序

由于increment()通过this关键字返回当前对象的句柄, 所以可以方便地对同一个对象执行多项操作。

1. 在构建器里调用构建器
若为一个类写了多个构建器, 那么经常都需要在一个构建器里调用另一个构建器, 以避免写重复的代码。可用this关键字做到这一点。
通常, 当我们说this的时候, 都是指“这个对象”或者“当前对象”。而且它本身会产生当前对象的一个句柄。在一个构建器中, 若为其赋予一个自变量列表, 那么this关键字会具有不同的含义：它会对与那个自变量列表相符的构建器进行明确的调用。这样一来, 我们就可通过一条直接的途径来调用其他构建器。如下所示：

160-161页程序

其中, 构建器Flower(String s,int petals)向我们揭示出这样一个问题：尽管可用this调用一个构建器, 但不可调用两个。除此以外, 构建器调用必须是我们做的第一件事情, 否则会收到编译程序的报错信息。
这个例子也向大家展示了this的另一项用途。由于自变量s的名字以及成员数据s的名字是相同的, 所以会出现混淆。为解决这个问题, 可用this.s来引用成员数据。经常都会在Java代码里看到这种形式的应用, 本书的大量地方也采用了这种做法。
在print()中, 我们发现编译器不让我们从除了一个构建器之外的其他任何方法内部调用一个构建器。

2. static的含义
理解了this关键字后, 我们可更完整地理解static（静态）方法的含义。它意味着一个特定的方法没有this。我们不可从一个static方法内部发出对非static方法的调用（注释②）, 尽管反过来说是可以的。而且在没有任何对象的前提下, 我们可针对类本身发出对一个static方法的调用。事实上, 那正是static方法最基本的意义。它就好象我们创建一个全局函数的等价物（在C语言中）。除了全局函数不允许在Java中使用以外, 若将一个static方法置入一个类的内部, 它就可以访问其他static方法以及static字段。

②：有可能发出这类调用的一种情况是我们将一个对象句柄传到static方法内部。随后, 通过句柄（此时实际是this）, 我们可调用非static方法, 并访问非static字段。但一般地, 如果真的想要这样做, 只要制作一个普通的、非static方法即可。

有些人抱怨static方法并不是“面向对象”的, 因为它们具有全局函数的某些特点；利用static方法, 我们不必向对象发送一条消息, 因为不存在this。这可能是一个清楚的自变量, 若您发现自己使用了大量静态方法, 就应重新思考自己的策略。然而, static的概念是非常实用的, 许多时候都需要用到它。所以至于它们是否真的“面向对象”, 应该留给理论家去讨论。事实上, 即使Smalltalk在自己的“类方法”里也有类似于static的东西。

4.3 清除：收尾和垃圾收集
程序员都知道“初始化”的重要性, 但通常忘记清除的重要性。毕竟, 谁需要来清除一个int呢？但是对于库来说, 用完后简单地“释放”一个对象并非总是安全的。当然, Java可用垃圾收集器回收由不再使用的对象占据的内存。现在考虑一种非常特殊且不多见的情况。假定我们的对象分配了一个“特殊”内存区域, 没有使用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()内部的一个固有方法中调用它。
读完上述文字后, 大家或许已弄清楚了自己不必过多地使用finalize()。这个思想是正确的；它并不是进行普通清除工作的理想场所。那么, 普通的清除工作应在何处进行呢？

4.3.2 必须执行清除
为清除一个对象, 那个对象的用户必须在希望进行清除的地点调用一个清除方法。这听起来似乎很容易做到, 但却与C++“破坏器”的概念稍有抵触。在C++中, 所有对象都会破坏（清除）。或者换句话说, 所有对象都“应该”破坏。若将C++对象创建成一个本地对象, 比如在堆栈中创建（在Java中是不可能的）, 那么清除或破坏工作就会在“结束花括号”所代表的、创建这个对象的作用域的末尾进行。若对象是用new创建的（类似于Java）, 那么当程序员调用C++的delete命令时（Java没有这个命令）, 就会调用相应的破坏器。若程序员忘记了, 那么永远不会调用破坏器, 我们最终得到的将是一个内存“漏洞”, 另外还包括对象的其他部分永远不会得到清除。
相反, Java不允许我们创建本地（局部）对象——无论如何都要使用new。但在Java中, 没有“delete”命令来释放对象, 因为垃圾收集器会帮助我们自动释放存储空间。所以如果站在比较简化的立场, 我们可以说正是由于存在垃圾收集机制, 所以Java没有破坏器。然而, 随着以后学习的深入, 就会知道垃圾收集器的存在并不能完全消除对破坏器的需要, 或者说不能消除对破坏器代表的那种机制的需要（而且绝对不能直接调用finalize(), 所以应尽量避免用它）。若希望执行除释放存储空间之外的其他某种形式的清除工作, 仍然必须调用Java中的一个方法。它等价于C++的破坏器, 只是没后者方便。
finalize()最有用处的地方之一是观察垃圾收集的过程。下面这个例子向大家展示了垃圾收集所经历的过程, 并对前面的陈述进行了总结。

165-166页程序

上面这个程序创建了许多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

167-168页程序

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

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

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

4.4 成员初始化
Java尽自己的全力保证所有变量都能在使用前得到正确的初始化。若被定义成相对于一个方法的“局部”变量, 这一保证就通过编译期的出错提示表现出来。因此, 如果使用下述代码：

void f() {
int i;
i++;
}

就会收到一条出错提示消息, 告诉你i可能尚未初始化。当然, 编译器也可为i赋予一个默认值, 但它看起来更象一个程序员的失误, 此时默认值反而会“帮倒忙”。若强迫程序员提供一个初始值, 就往往能够帮他／她纠出程序里的“臭虫”。
然而, 若将基本类型（主类型）设为一个类的数据成员, 情况就会变得稍微有些不同。由于任何方法都可以初始化或使用那个数据, 所以在正式使用数据前, 若还是强迫程序员将其初始化成一个适当的值, 就可能不是一种实际的做法。然而, 若为其赋予一个垃圾值, 同样是非常不安全的。因此, 一个类的所有基本类型数据成员都会保证获得一个初始值。可用下面这段小程序看到这些值：

169页程序

输入结果如下：

170页上程序

其中, Char值为空（NULL）, 没有数据打印出来。
稍后大家就会看到：在一个类的内部定义一个对象句柄时, 如果不将其初始化成新对象, 那个句柄就会获得一个空值。

4.4.1 规定初始化
如果想自己为变量赋予一个初始值, 又会发生什么情况呢？为达到这个目的, 一个最直接的做法是在类内部定义变量的同时也为其赋值（注意在C++里不能这样做, 尽管C++的新手们总“想”这样做）。在下面, Measurement类内部的字段定义已发生了变化, 提供了初始值：

170页下程序

亦可用相同的方法初始化非基本（主）类型的对象。若Depth是一个类, 那么可象下面这样插入一个变量并进行初始化：

class Measurement {
Depth o = new Depth();
boolean b = true;
// . . .

若尚未为o指定一个初始值, 同时不顾一切地提前试用它, 就会得到一条运行期错误提示, 告诉你产生了名为“违例”（Exception）的一个错误（在第9章详述）。
甚至可通过调用一个方法来提供初始值：

class CInit {
int i = f();
//...
}

当然, 这个方法亦可使用自变量, 但那些自变量不可是尚未初始化的其他类成员。因此, 下面这样做是合法的：

class CInit {
int i = f();
int j = g(i);
//...
}

但下面这样做是非法的：

class CInit {
int j = g(i);
int i = f();
//...
}

这正是编译器对“向前引用”感到不适应的一个地方, 因为它与初始化的顺序有关, 而不是与程序的编译方式有关。
这种初始化方法非常简单和直观。它的一个限制是类型Measurement的每个对象都会获得相同的初始化值。有时, 这正是我们希望的结果, 但有时却需要盼望更大的灵活性。

4.4.2 构建器初始化
可考虑用构建器执行初始化进程。这样便可在编程时获得更大的灵活程度, 因为我们可以在运行期调用方法和采取行动, 从而“现场”决定初始化值。但要注意这样一件事情：不可妨碍自动初始化的进行, 它在构建器进入之前就会发生。因此, 假如使用下述代码：

class Counter {
int i;
Counter() { i = 7; }
// . . .

那么i首先会初始化成零, 然后变成7。对于所有基本类型以及对象句柄, 这种情况都是成立的, 其中包括在定义时已进行了明确初始化的那些一些。考虑到这个原因, 编译器不会试着强迫我们在构建器任何特定的场所对元素进行初始化, 或者在它们使用之前——初始化早已得到了保证（注释⑤）。

⑤：相反, C++有自己的“构建器初始模块列表”, 能在进入构建器主体之前进行初始化, 而且它对于对象来说是强制进行的。参见《Thinking in C++》。

1. 初始化顺序
在一个类里, 初始化的顺序是由变量在类内的定义顺序决定的。即使变量定义大量遍布于方法定义的中间, 那些变量仍会在调用任何方法之前得到初始化——甚至在构建器调用之前。例如：

172-173页程序

在Card中, Tag对象的定义故意到处散布, 以证明它们全都会在构建器进入或者发生其他任何事情之前得到初始化。除此之外, t3在构建器内部得到了重新初始化。它的输入结果如下：

173页中程序

因此, t3句柄会被初始化两次, 一次在构建器调用前, 一次在调用期间（第一个对象会被丢弃, 所以它后来可被当作垃圾收掉）。从表面看, 这样做似乎效率低下, 但它能保证正确的初始化——若定义了一个过载的构建器, 它没有初始化t3；同时在t3的定义里并没有规定“默认”的初始化方式, 那么会产生什么后果呢？

2. 静态数据的初始化
若数据是静态的（static）, 那么同样的事情就会发生；如果它属于一个基本类型（主类型）, 而且未对其初始化, 就会自动获得自己的标准基本类型初始值；如果它是指向一个对象的句柄, 那么除非新建一个对象, 并将句柄同它连接起来, 否则就会得到一个空值（NULL）。
如果想在定义的同时进行初始化, 采取的方法与非静态值表面看起来是相同的。但由于static值只有一个存储区域, 所以无论创建多少个对象, 都必然会遇到何时对那个存储区域进行初始化的问题。下面这个例子可将这个问题说更清楚一些：

174-175页程序

Bowl允许我们检查一个类的创建过程, 而Table和Cupboard能创建散布于类定义中的Bowl的static成员。注意在static定义之前, Cupboard先创建了一个非static的Bowl b3。它的输出结果如下：

175页中程序

static初始化只有在必要的时候才会进行。如果不创建一个Table对象, 而且永远都不引用Table.b1或Table.b2, 那么static Bowl b1和b2永远都不会创建。然而, 只有在创建了第一个Table对象之后（或者发生了第一次static访问）, 它们才会创建。在那以后, static对象不会重新初始化。
初始化的顺序是首先static（如果它们尚未由前一次对象创建过程初始化）, 接着是非static对象。大家可从输出结果中找到相应的证据。
在这里有必要总结一下对象的创建过程。请考虑一个名为Dog的类：
(1) 类型为Dog的一个对象首次创建时, 或者Dog类的static方法／static字段首次访问时, Java解释器必须找到Dog.class（在事先设好的类路径里搜索）。
(2) 找到Dog.class后（它会创建一个Class对象, 这将在后面学到）, 它的所有static初始化模块都会运行。因此, static初始化仅发生一次——在Class对象首次载入的时候。
(3) 创建一个new Dog()时, Dog对象的构建进程首先会在内存堆（Heap）里为一个Dog对象分配足够多的存储空间。
(4) 这种存储空间会清为零, 将Dog中的所有基本类型设为它们的默认值（零用于数字, 以及boolean和char的等价设定）。
(5) 进行字段定义时发生的所有初始化都会执行。
(6) 执行构建器。正如第6章将要讲到的那样, 这实际可能要求进行相当多的操作, 特别是在涉及继承的时候。

3. 明确进行的静态初始化
Java允许我们将其他static初始化工作划分到类内一个特殊的“static构建从句”（有时也叫作“静态块”）里。它看起来象下面这个样子：

176页下程序

尽管看起来象个方法, 但它实际只是一个static关键字, 后面跟随一个方法主体。与其他static初始化一样, 这段代码仅执行一次——首次生成那个类的一个对象时, 或者首次访问属于那个类的一个static成员时（即便从未生成过那个类的对象）。例如：

176-177页程序

在标记为(1)的行内访问static对象c1的时候, 或在行(1)标记为注释, 同时(2)行不标记成注释的时候, 用于Cups的static初始化模块就会运行。若(1)和(2)都被标记成注释, 则用于Cups的static初始化进程永远不会发生。

4. 非静态实例的初始化
针对每个对象的非静态变量的初始化, Java 1.1提供了一种类似的语法格式。下面是一个例子：

177-178页程序

大家可看到实例初始化从句：

178页下程序

它看起来与静态初始化从句极其相似, 只是static关键字从里面消失了。为支持对“匿名内部类”的初始化（参见第7章）, 必须采用这一语法格式。

4.5 数组初始化
在C中初始化数组极易出错, 而且相当麻烦。C++通过“集合初始化”使其更安全（注释⑥）。Java则没有象C++那样的“集合”概念, 因为Java中的所有东西都是对象。但它确实有自己的数组, 通过数组初始化来提供支持。
数组代表一系列对象或者基本数据类型, 所有相同的类型都封装到一起——采用一个统一的标识符名称。数组的定义和使用是通过方括号索引运算符进行的（[]）。为定义一个数组, 只需在类型名后简单地跟随一对空方括号即可：
int[] al;
也可以将方括号置于标识符后面, 获得完全一致的结果：
int al[];
这种格式与C和C++程序员习惯的格式是一致的。然而, 最“通顺”的也许还是前一种语法, 因为它指出类型是“一个int数组”。本书将沿用那种格式。
编译器不允许我们告诉它一个数组有多大。这样便使我们回到了“句柄”的问题上。此时, 我们拥有的一切就是指向数组的一个句柄, 而且尚未给数组分配任何空间。为了给数组创建相应的存储空间, 必须编写一个初始化表达式。对于数组, 初始化工作可在代码的任何地方出现, 但也可以使用一种特殊的初始化表达式, 它必须在数组创建的地方出现。这种特殊的初始化是一系列由花括号封闭起来的值。存储空间的分配（等价于使用new）将由编译器在这种情况下进行。例如：
int[] a1 = { 1, 2, 3, 4, 5 };
那么为什么还要定义一个没有数组的数组句柄呢？
int[] a2;
事实上在Java中, 可将一个数组分配给另一个, 所以能使用下述语句：
a2 = a1;
我们真正准备做的是复制一个句柄, 就象下面演示的那样：

180页上程序

大家看到a1获得了一个初始值, 而a2没有；a2将在以后赋值——这种情况下是赋给另一个数组。
这里也出现了一些新东西：所有数组都有一个本质成员（无论它们是对象数组还是基本类型数组）, 可对其进行查询——但不是改变, 从而获知数组内包含了多少个元素。这个成员就是length。与C和C++类似, 由于Java数组从元素0开始计数, 所以能索引的最大元素编号是“length-1”。如超出边界, C和C++会“默默”地接受, 并允许我们胡乱使用自己的内存, 这正是许多程序错误的根源。然而, Java可保留我们这受这一问题的损害, 方法是一旦超过边界, 就生成一个运行期错误（即一个“违例”, 这是第9章的主题）。当然, 由于需要检查每个数组的访问, 所以会消耗一定的时间和多余的代码量, 而且没有办法把它关闭。这意味着数组访问可能成为程序效率低下的重要原因——如果它们在关键的场合进行。但考虑到因特网访问的安全, 以及程序员的编程效率, Java设计人员还是应该把它看作是值得的。
程序编写期间, 如果不知道在自己的数组里需要多少元素, 那么又该怎么办呢？此时, 只需简单地用new在数组里创建元素。在这里, 即使准备创建的是一个基本数据类型的数组, new也能正常地工作（new不会创建非数组的基本类型）：

180-181页程序

由于数组的大小是随机决定的（使用早先定义的pRand()方法）, 所以非常明显, 数组的创建实际是在运行期间进行的。除此以外, 从这个程序的输出中, 大家可看到基本数据类型的数组元素会自动初始化成“空”值（对于数值, 空值就是零；对于char, 它是null；而对于boolean, 它却是false）。
当然, 数组可能已在相同的语句中定义和初始化了, 如下所示：
int[] a = new int[pRand(20)];
若操作的是一个非基本类型对象的数组, 那么无论如何都要使用new。在这里, 我们会再一次遇到句柄问题, 因为我们创建的是一个句柄数组。请大家观察封装器类型Integer, 它是一个类, 而非基本数据类型：

181-182页程序

在这儿, 甚至在new调用后才开始创建数组：
Integer[] a = new Integer[pRand(20)];
它只是一个句柄数组, 而且除非通过创建一个新的Integer对象, 从而初始化了对象句柄, 否则初始化进程不会结束：
a[i] = new Integer(pRand(500));
但若忘记创建对象, 就会在运行期试图读取空数组位置时获得一个“违例”错误。
下面让我们看看打印语句中String对象的构成情况。大家可看到指向Integer对象的句柄会自动转换, 从而产生一个String, 它代表着位于对象内部的值。
亦可用花括号封闭列表来初始化对象数组。可采用两种形式, 第一种是Java 1.0允许的唯一形式。第二种（等价）形式自Java 1.1才开始提供支持：

182-183页程序

这种做法大多数时候都很有用, 但限制也是最大的, 因为数组的大小是在编译期间决定的。初始化列表的最后一个逗号是可选的（这一特性使长列表的维护变得更加容易）。
数组初始化的第二种形式（Java 1.1开始支持）提供了一种更简便的语法, 可创建和调用方法, 获得与C的“变量参数列表”（C通常把它简称为“变参表”）一致的效果。这些效果包括未知的参数（自变量）数量以及未知的类型（如果这样选择的话）。由于所有类最终都是从通用的根类Object中继承的, 所以能创建一个方法, 令其获取一个Object数组, 并象下面这样调用它：

183页中程序

此时, 我们对这些未知的对象并不能采取太多的操作, 而且这个程序利用自动String转换对每个Object做一些有用的事情。在第11章（运行期类型标识或RTTI）, 大家还会学习如何调查这类对象的准确类型, 使自己能对它们做一些有趣的事情。

4.5.1 多维数组
在Java里可以方便地创建多维数组：

184-185页程序

用于打印的代码里使用了length, 所以它不必依赖固定的数组大小。
第一个例子展示了基本数据类型的一个多维数组。我们可用花括号定出数组内每个矢量的边界：

int[][] a1 = {
{ 1, 2, 3, },
{ 4, 5, 6, },
};

每个方括号对都将我们移至数组的下一级。
第二个例子展示了用new分配的一个三维数组。在这里, 整个数组都是立即分配的：
int[][][] a2 = new int[2][2][4];
但第三个例子却向大家揭示出构成矩阵的每个矢量都可以有任意的长度：

186页上程序

对于第一个new创建的数组, 它的第一个元素的长度是随机的, 其他元素的长度则没有定义。for循环内的第二个new则会填写元素, 但保持第三个索引的未定状态——直到碰到第三个new。
根据输出结果, 大家可以看到：假若没有明确指定初始化值, 数组值就会自动初始化成零。
可用类似的表式处理非基本类型对象的数组。这从第四个例子可以看出, 它向我们演示了用花括号收集多个new表达式的能力：

186页中程序

第五个例子展示了如何逐渐构建非基本类型的对象数组：

186页下程序

i*j只是在Integer里置了一个有趣的值。

4.6 总结
作为初始化的一种具体操作形式, 构建器应使大家明确感受到在语言中进行初始化的重要性。与C++的程序设计一样, 判断一个程序效率如何, 关键是看是否由于变量的初始化不正确而造成了严重的编程错误（臭虫）。这些形式的错误很难发现, 而且类似的问题也适用于不正确的清除或收尾工作。由于构建器使我们能保证正确的初始化和清除（若没有正确的构建器调用, 编译器不允许对象创建）, 所以能获得完全的控制权和安全性。
在C++中, 与“构建”相反的“破坏”（Destruction）工作也是相当重要的, 因为用new创建的对象必须明确地清除。在Java中, 垃圾收集器会自动为所有对象释放内存, 所以Java中等价的清除方法并不是经常都需要用到的。如果不需要类似于构建器的行为, Java的垃圾收集器可以极大简化编程工作, 而且在内存的管理过程中增加更大的安全性。有些垃圾收集器甚至能清除其他资源, 比如图形和文件句柄等。然而, 垃圾收集器确实也增加了运行期的开销。但这种开销到底造成了多大的影响却是很难看出的, 因为到目前为止, Java解释器的总体运行速度仍然是比较慢的。随着这一情况的改观, 我们应该能判断出垃圾收集器的开销是否使Java不适合做一些特定的工作（其中一个问题是垃圾收集器不可预测的性质）。
由于所有对象都肯定能获得正确的构建, 所以同这儿讲述的情况相比, 构建器实际做的事情还要多得多。特别地, 当我们通过“创作”或“继承”生成新类的时候, 对构建的保证仍然有效, 而且需要一些附加的语法来提供对它的支持。大家将在以后的章节里详细了解创作、继承以及它们对构建器造成的影响。

4.7 练习
(1) 用默认构建器创建一个类（没有自变量）, 用它打印一条消息。创建属于这个类的一个对象。
(2) 在练习1的基础上增加一个过载的构建器, 令其采用一个String自变量, 并随同自己的消息打印出来。
(3) 以练习2创建的类为基础上, 创建属于它的对象句柄的一个数组, 但不要实际创建对象并分配到数组里。运行程序时, 注意是否打印出来自构建器调用的初始化消息。
(4) 创建同句柄数组联系起来的对象, 最终完成练习3。
(5) 用自变量“before”, “after”和“none”运行程序, 试验Garbage.java。重复这个操作, 观察是否从输出中看出了一些固定的模式。改变代码, 使System.runFinalization()在System.gc()之前调用, 再观察结果。