一、和C++的区别
程序员都了解初始化的重要性，但常常会忘记同样也重要的清理工作。毕竟，谁需要清理一个int呢？但在使用程序库时，把一个对象用完后就“弃之不顾”的做法并非总是安全的。当然，java有垃圾回收器负责回收无用对象占据的内存资源。但也有特殊情况：假定你的对象（并非使用new）获得了一块“特殊”的内存区域，由于垃圾回收器只知道释放那些经由new分配的内存，所以它不知道该如何释放该对象的这块“特殊”内存。为了应对这种情况，java允许在类中定义一个名为finalize()的方法。他的工作原理“假定”是这样的：一旦垃圾回收器准备好释放对象占用的存储空间，将首先调用其finalize()方法，并且在下一次垃圾回收动作发生时，才会真正回收对象占用的内存。所以要是你打算用finalize()，就能在垃圾回收时刻做一些重要的清理工作。
这里有一个潜在的编程陷阱，因为有些程序员（特别是C++程序员）刚开始可能会误把finalize()当作C++中的析构函数（C++中销毁对象必须用到这个函数）。所以有必要明确区分一下：在C++中，对象一定会被销毁（如果程序中没有缺陷的话）；而java里的对象却并非总是被垃圾回收。或者换句话说：
- 对象可能不被垃圾回收。
- 垃圾回收并不等于“析构”。
牢记这些，就能远离困扰。这意味着在你不再需要某个对象之前，如果必须执行某些动作，那么你得自己去做。Java并未提供“析构函数”或相似的概念，要做类似的清理工作，必须自己动手创建一个执行清理工作的普通方法。例如，假设某个对象在创建过程中会将自己绘制到屏幕上，如果不是明确地从屏幕上将其檫除，他可能永远得不到清理。如果在finalize()里加入某种檫除功能，当“垃圾回收”发生时（不能保证一定会发生），finalize()得到了调用，图像就会被檫除。要是“垃圾回收”没有发生，图像就会一直保留下来。
也许你会发现，只要程序没有濒临存储空间用完的那一刻，对象占用的空间就总也得不到释放。如果程序执行结束，并且垃圾回收器一直都没有释放你创建的任何对象的存储空间，则随着程序的退出，那些资源也会全部交还给操作系统。这个策略是恰当的，因为垃圾回收本身也有开销，要是不使用它，那就不用支付这部分开销了。
二、finalize()的用途
此时，已经明白了不该将finalize()作为通用的清理方法。那么，finalize()的真正用途是什么呢？使用垃圾回收器的唯一原因是为了回收程序不再使用的内存。所以对于与垃圾回收有关的任何行为来说（尤其是finalize()方法），它们也必须同内存及其回收有关。
但这是否意味着要是对象中含有其他对象，finalize()就应该明确释放这些对象呢？不，无论对象是如何创建的，垃圾回收器都会负责释放对象占据的所有内存。这就将对finalize()的需求限制到一种特殊情况，即通过某种创建对象方式以外的方式为对象分配了存储空间。不过，java中一切皆为对象，那这种特殊情况是怎么回事呢？
看来之所以要有finalize()，是由于在分配内存时可能采用了类似C语言中的做法，而非java中的通常做法。这种情况主要发生在使用“本地方法”的情况下，本地方法是一种在java中调用非java代码的方式。在非java代码中，也许会调用C的malloc()函数系列来分配存储空间，而且除非调用free()函数，否则存储空间将得不到释放，从而造成内存泄漏。当然，free()是C和C++中的函数，所以需要在finalize()中用本地方法调用它。
finalize()确实不是进行普通清理工作的合适场所。那么，普通的清理工作应该在哪里执行呢？
三、实施清理
要清理一个对象，用户必须在需要清理的时刻调用执行清理动作的方法。这听起来似乎很简单，但却与C++中的“析构函数”的概念稍有抵触。在C++中，所有对象都会被销毁，或者说，应该被销毁。如果在C++中创建了一个局部对象（也就是在堆栈上创建，这在java中行不通），此时的销毁动作发生在以“右花括号”为边界的、此对象作用域的末尾处。如果对象使用new创建的（类似于java中），那么当程序员调用C++的delete操作符时（java没有这个命令），就会调用相应的析构函数。如果程序员忘记调用delete，那么永远不会调用析构函数，这样就会出现内存泄漏，对象的其他部分也不会得到清理。这种缺陷很难跟踪，这也是让C++程序员转向java的一个主要因素。
相反，java不允许创建局部对象，必须使用new创建对象。在java中，也没有用于释放对象的delete，因为垃圾回收器会帮助你释放存储空间。甚至可以肤浅的认为，正是由于垃圾收集机制的存在，使得java没有析构函数。然而，随着学习的深入，就会明白垃圾回收器的存在并不能完全代替析构函数。（而且绝对不能直接调用finalize()，所以这也不是一种解决方案。）如果希望进行除释放存储空间之外的清理工作，还是得明确调用某个恰当的java方法。这就等同于使用析构函数了，只是没有它方便。
记住，无论是“垃圾回收”还是“终结”，都不保证一定会发生。如果java虚拟机（JVM）并未面临内存耗尽的情形，他是不会浪费时间去执行垃圾回收以恢复内存的。
四、终结条件
通常，不能指望finalize()，必须创建其他的“清理”方法，并且明确地调用它们。看来，finalize()只能存在于程序员很难用到的一些晦涩用法里了。不过，finalize()还有一个有趣的用法，它并不依赖于每次都要对finalize()进行调用，这就是对象终结条件的验证。
当对某个对象不再感兴趣--也就是它可以被清理了，这个对象应该处于某种状态，使他它占用的内存可以被安全地释放。例如，要是对象代表了一个打开的文件，在对象被回收前程序员应该关闭这个文件。只要对象中存在没有没有被适当清理的部分，程序就存在很隐晦的缺陷。finalize()可以用来最终发现这种情况--尽管它并不总是会被调用。如果某次finalize()的动作使得缺陷被发现，那么就可据此找出问题所在--这才是人们真正关心的。
一下是个简单的例子，示范了finalize()可能的使用方式：
class Book {
boolean checkedOut = false;
Book(boolean checkOut) {
checkedOut = checkOut;
}
void checkIn() {
checkedOut = false;
}
protected void finalize() {
if (checkedOut) {
System.out.println("Error:check out");
// super.finalize();
}
}
}
public class TerminationCondition {
public static void main(String[] args) {
Book novel = new Book(true);
novel.checkIn();
new Book(true);
System.gc();
}
}本例的总结条件是：所有的Book对象在被当做垃圾回收前都应该被签入（check in）。但在main()方法中，由于程序员的错误，有一本书未被签入。要是没有finalize()来验证终结条件，将很难发现这种缺陷。
注意，System,gc()用于强制进行终结动作。即使不这么做，通过重复地执行程序（假设程序将分配大量的存储空间而导致垃圾回收动作的执行），最终也能找出错误的Book对象。
你应该总是假设基类版本的finalize()也要做某些重要的事情，因此要使用super来调用它，就像在Book.finalize()中看到的那样。在本例中，它被注释掉了。
五、垃圾回收器如何工作
在以前所用过的程序语言中，在堆上分配对象的代价十分高昂，因此自然会觉得java中所有对象（基本类型除外）都在堆上分配的方式也非常高昂。然而，垃圾回收器对于提高对象的创建速度，却具有明显的效果。听起来很奇怪--存储空间的释放竟然会影响存储空间的分配，但这确实是某些java虚拟机的工作方式。这也意味着，java从堆分配空间的速度，可以和其他语言从堆栈上分配空间的速度相媲美。
打个比方，你可以把C++里的堆想象成一个院子，里面每个对象都负责管理自己的地盘。一段时间以后，对象可能被销毁，但地盘必须加以重用。在某些java虚拟机中，堆得实现截然不同：它更像一个传送带，每分配一个新对象，它就往前移动一格。这意味着对象存储空间的分配速度非常快。java的“堆指针”只是简单地移动到尚未分配的区域，其效率比得上C++在堆栈上分配空间的效率。当然，实际过程中在簿记工作方面还有少量额外的开销，但比不上查找所用的开销。
java中的堆未必完全像传送带那样的工作。要是那样的话，势必会导致频繁的内存页面调度--将其移进移出硬盘，因此会显得需要拥有比实际需要更多的内存。页面调度会显著的影响性能，最终，在创建了足够多的对象之后，内存资源将耗尽。其中的秘密在于垃圾回收器的介入。当它工作时，将一面回收空间，一面使堆中的对象紧凑排列，这样“堆指针”就可以很容易移动到更靠近传送带的开始处，也就尽量避免了页面错误。通过垃圾回收器对对象重新排列，实现了一种高速的、有无限空间可供分配的堆模型。
想要更好地理解java中的垃圾回收，先了解其他系统中的垃圾回收机制将会很有帮助。引用记数是一种简单但速度很慢的垃圾回收技术。每个对象都含有一个引用计数器，当有引用连接至对象时，引用记数加1.当引用离开作用域或被置为null时，引用计数减1。虽然管理引用记数的开销不大，但这项开销在整个程序生命周期中将持续发生。垃圾回收器会在含有全部对象的列表上遍历，当发现某个对象的引用计数为0时，就释放其占用的空间（但是，引用记数模式经常会在记数值变为0时立即释放对象）。这种方法有个缺陷，如果对象之间存在循环引用，可能就会出现“对象应该被回收，但引用计数却不为零”的情况。对垃圾回收器而言，定位这样的交互自引用的对象组所需的工作量极大。引用记数常用来说明垃圾收集的工作方式，但似乎从未被应用于任何一种java虚拟机实现中。
在一些更快的模式中，垃圾回收器并非基于引用记数技术。它们依据的思想是：对任何“活”的对象，一定能最终追溯到其存活在堆栈或静态存储区之中的引用。这个引用链条可能会穿过数个对象层次。由此，如果从堆栈和静态存储区开始，遍历所有的引用，就能找到所有“活”的对象。对于发现的每个引用，必须追踪它所引用的对象，然后是此对象包含的所有引用，如此反复进行，直到“根源于堆栈和静态存储区的引用”所形成的网络全部被访问为止。你所访问过的对象必须都是“活”的。注意，这就解决了“交互自引用的对象组”的问题--这种现象根本不会被发现，因此也就被自动回收了。
在这种情况下，java虚拟机将采用一种自适应的垃圾回收技术。至于如何处理找到的存活对象，取决于不同的java虚拟机实现。有一种做法名为停止--复制（stop and copy）。显然这意味着，先暂停程序的运行（所以它不属于后台回收模式），然后将所有存活的对象从当前堆复制到另一个堆，没有被复制的全部都是垃圾。当对象被复制到新堆时，它们是一个挨着一个的，所以新堆保持紧凑排列，然后就可以按前述方法简单，直接地分配新空间了。
当把对象从一处搬到另一处时，所有指向它的那些引用都必须修正。位于堆或静态存储区的引用可以直接被修正，但可能还有其他指向这些对象的引用，它们在遍历的过程中才能被找到（可以想象成有个表格，将旧地址映射至新地址）。
对于这种所谓的“复制式回收器”而言，效率会降低，这有两个原因。首先，得有两个堆，然后得在这两个分离的堆之间来回倒腾，从而得维护比实际都需要多一倍的空间。某些java虚拟机对此问题的处理方式是，按需从堆中分配几块较大的内存，复制动作发生在这些大块内存之间。
第二个问题在于复制。程序进入稳定状态之后，可能只会产生少量的垃圾，甚至没有垃圾。尽管如此，复制式回收器仍然会将所有内存自一处复制到另一处，这很浪费。为了避免这种情形，一些java虚拟机会进行检查：要是没有新垃圾的产生，就会转换到另一种工作模式（即“自适应”）。这种模式称为标记--清扫（mark and sweep），Sun公司早期版本的java虚拟机使用了这种技术。对一般用途而言，“标记--清扫”方式速度非常慢，但是当你知道只会产生少量垃圾甚至不会产生垃圾时，它的速度就很快了。
“标记--清扫”所依据的思路同样是从堆栈和静态存储区出发，遍历所有的引用，进而找出所有存活的对象。每当它找到一个存活对象，就会给对象设一个标记，这个过程中不会回收任何对象。只有全部标记工作完成的时候，清理动作才会开始。在清理过程中，没有标记的对象将被释放，不会发生任何复制动作。所以剩下的堆空间不是连续的，垃圾回收器要是希望得到连续空间的话，就得重新整理剩下的对象。
“停止--复制”的意思是这种垃圾回收动作不是在后台进行的；相反，垃圾回收动作发生的同时，程序将会被暂停。在Sun公司的文档中会发现，许多参考文献将垃圾回收视为低优先级的后台进程，但事实上垃圾回收器在Sun公司早期版本的java虚拟机中并非以这种方式实现的。当可用内存数量比较低时，Sun版本的垃圾回收器会暂停运行程序，同样，“标记--清扫”工作也必须在程序暂停的情况下才能运行。
如前所述，在这里所讨论的java虚拟机中，内存分配以较大的“块”为单位。如果对象较大，它会占用单独的块。严格来说，“停止--赋值”要求在释放旧有对象之前，必须先把所有存活对象从旧堆复制到新堆，这将导致大量内存复制行为。有了块之后，垃圾回收器在回收的时候就可以往废弃的块里拷贝对象了。每个块都用相应的代数（generation count）来记录它是否还存活。通常，如果块在某处被引用，其代数会增加；垃圾回收器将对上次回收动作之后新分配的块进行清理。这对处理大量短命的临时对象很有帮助。垃圾回收器会定期进行完整的清理动作--大型对象仍然不会被复制（只是其代数会增加），内含小型对象的那些块则被复制并整理。java虚拟机会进行监视，如果所有对象都很稳定，垃圾回收器的效率降低的话，就切换到“标记--清扫”方式；同样，java虚拟机会跟踪“标记--清扫”的效果，要是堆空间出现很多碎片，就会切换回“停止--复制”方式。这就是“自适应”技术，你可以给它个啰嗦的称呼：“自适应的、分代的、停止--复制、标记--清扫”式垃圾回收器。
java虚拟机中有许多附加技术用以提升速度。尤其是与加载器操作有关的，被称为“即时”（Just In Time，JIT）编译器的技术。这种技术可以把程序全部或部分翻译成本地机器码（这本来是java虚拟机的工作），程序运行速度因此得以提升。当需要装载某个类（通常是在为该类创建第一个对象）时，编译器会先找到其.class文件，然后将该类的字节码装入内存。此时，有两种方案可供选择。一种是就让即时编译器编译所有代码。但这种做法有两个缺陷：这种加载动作散落在整个程序生命周期内，累加起来要花更多时间；并且会增加可执行代码的长度（字节码要比即时编译器展开后的本地机器码小很多），这将导致页面调度，从而降低程序速度。另一种做法称为惰性评估（lazy evaluation），意思是即时编译器只在必要的时候才编译代码。这样，从不会被执行的代码也许就压根不会被JIT所编译。新版本JDK中的java HotSpot技术就采用了类似方法，代码每次被执行的时候都会做一些优化，所以执行的次数越多，它的速度就越快。
