一. 垃圾回收的意义
在C++中，对象所占的内存在程序结束运行之前一直被占用，在明确释放之前不能分配给其它对象；而在Java中，当没有对象引用指向原先分配给某个对象的内存时，该内存便成为垃圾。JVM的一个系统级线程会自动释放该内存块。垃圾回收意味着程序不再需要的对象是"无用信息"，这些信息将被丢弃。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。事实上，除了释放没用的对象，垃圾回收也可以清除内存记录碎片。由于创建对象和垃圾回收器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆的一端，JVM将整理出的内存分配给新的对象。
垃圾回收能自动释放内存空间，减轻编程的负担。这使Java 虚拟机具有一些优点。首先，它能使编程效率提高。在没有垃圾回收机制的时候，可能要花许多时间来解决一个难懂的存储器问题。在用Java语言编程的时候，靠垃圾回收机制可大大缩短时间。其次是它保护程序的完整性， 垃圾回收是Java语言安全性策略的一个重要部份。
垃圾回收的一个潜在的缺点是它的开销影响程序性能。Java虚拟机必须追踪运行程序中有用的对象，而且最终释放没用的对象。这一个过程需要花费处理器的时间。其次垃圾回收算法的不完备性，早先采用的某些垃圾回收算法就不能保证100%收集到所有的废弃内存。当然随着垃圾回收算法的不断改进以及软硬件运行效率的不断提升，这些问题都可以迎刃而解。
二、垃圾收集的算法分析
既然是要进行自动GC，那必然会有相应的策略，而这些策略解决了哪些问题呢，粗略的来说，主要有以下几点。
1、哪些对象可以被回收。
2、何时回收这些对象。
3、采用什么样的方式回收。
具体算法：
1、引用计数法(Reference Counting Collector)
引用计数法是唯一没有使用根集的垃圾回收的法，该算法使用引用计数器来区分存活对象和不再使用的对象。一般来说，堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就满足了垃圾收集的条件。
基于引用计数器的垃圾收集器运行较快，但是有个致命缺陷：那就是对于循环引用的对象无法进行回收。
public class Object {
Object field = null;
public static void main(String[] args) {
Thread thread = new Thread(new Runnable() {
public void run() {
Object objectA = new Object();
Object objectB = new Object();//1
objectA.field = objectB;
objectB.field = objectA;//2
//to do something
objectA = null;
objectB = null;//3
}
});
thread.start();
while (true);
}
}
标注了1、2、3三个数字，当第1个地方的语句执行完以后，两个对象的引用计数全部为1。当第2个地方的语句执行完以后，两个对象的引用计数就全部变成了2。当第3个地方的语句执行完以后，也就是将二者全部归为空值以后，二者的引用计数仍然为1。根据引用计数算法的回收规则，引用计数没有归0的时候是不会被回收的。
根搜索算法
大多数垃圾回收算法使用了根集(root set)这个概念；所谓根集就是正在执行的Java程序可以访问的引用变量的集合(包括局部变量、参数、类变量)，程序可以使用引用变量访问对象的属性和调用对象的方法。垃圾回收首先需要确定从根开始哪些是可达的和哪些是不可达的，从根集可达的对象都是活动对象，它们不能作为垃圾被回收，这也包括从根集间接可达的对象。而根集通过任意路径不可达的对象符合垃圾收集的条件，应该被回收。下面介绍几个常用的算法。说到GC roots（GC根），在JAVA语言中，可以当做GC roots的对象有以下几种：1、虚拟机栈中的引用的对象。2、方法区中的类静态属性引用的对象。3、方法区中的常量引用的对象。4、本地方法栈中JNI的引用的对象。
第一和第四种都是指的方法的本地变量表，第二种表达的意思比较清晰，第三种主要指的是声明为final的常量值
2、tracing算法(Tracing Collector) 标记-清除
根搜索算法，它可以解决我们应该回收哪些对象的问题，但是它显然还不能承担垃圾搜集的重任，因为我们在程序（程序也就是指我们运行在JVM上的JAVA程序）运行期间如果想进行垃圾回收，就必须让GC线程与程序当中的线程互相配合，才能在不影响程序运行的前提下，顺利的将垃圾进行回收。
为了达到这个目的，标记/清除算法就应运而生了。它的做法是当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被成为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。
下面LZ具体解释一下标记和清除分别都会做些什么。
标记：标记的过程其实就是，遍历所有的GC Roots，然后将所有GC Roots可达的对象标记为存活的对象。
清除：清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。
其实这两个步骤并不是特别复杂，也很容易理解。LZ用通俗的话解释一下标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。
下面LZ给各位制作了一组描述上面过程的图片，结合着图片，我们来直观的看下这一过程，首先是第一张图。
这张图代表的是程序运行期间所有对象的状态，它们的标志位全部是0（也就是未标记，以下默认0就是未标记，1为已标记），假设这会儿有效内存空间耗尽了，JVM将会停止应用程序的运行并开启GC线程，然后开始进行标记工作，按照根搜索算法，标记完以后，对象的状态如下图。
可以看到，按照根搜索算法，所有从root对象可达的对象就被标记为了存活的对象，此时已经完成了第一阶段标记。接下来，就要执行第二阶段清除了，那么清除完以后，剩下的对象以及对象的状态如下图所示。
可以看到，没有被标记的对象将会回收清除掉，而被标记的对象将会留下，并且会将标记位重新归0。接下来就不用说了，唤醒停止的程序线程，让程序继续运行即可。
其实这一过程并不复杂，甚至可以说非常简单，各位说对吗。不过其中有一点值得LZ一提，就是为什么非要停止程序的运行呢？
这个其实也不难理解，LZ举个最简单的例子，假设我们的程序与GC线程是一起运行的，各位试想这样一种场景。
假设我们刚标记完图中最右边的那个对象，暂且记为A，结果此时在程序当中又new了一个新对象B，且A对象可以到达B对象。但是由于此时A对象已经标记结束，B对象此时的标记位依然是0，因为它错过了标记阶段。因此当接下来轮到清除阶段的时候，新对象B将会被苦逼的清除掉。如此一来，不难想象结果，GC线程将会导致程序无法正常工作。
上面的结果当然令人无法接受，我们刚new了一个对象，结果经过一次GC，忽然变成null了，这还怎么玩？
到此为止，标记/清除算法LZ已经介绍完了，下面我们来看下它的缺点，其实了解完它的算法原理，它的缺点就很好理解了。
1、首先，它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲，尤其对于交互式的应用程序来说简直是无法接受。试想一下，如果你玩一个网站，这个网站一个小时就挂五分钟，你还玩吗？
2、第二点主要的缺点，则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。
3、compacting算法(Compacting Collector) 标记-整理
标记/整理算法与标记/清除算法非常相似，它也是分为两个阶段：标记和整理。下面LZ给各位介绍一下这两个阶段都做了什么。
标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历GC Roots，然后将存活的对象标记。
整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。
它GC前后的图示与复制算法的图非常相似，只不过没有了活动区间和空闲区间的区别，而过程又与标记/清除算法非常相似，我们来看GC前内存中对象的状态与布局，如下图所示。
这张图其实与标记/清楚算法一模一样，只是LZ为了方便表示内存规则的连续排列，加了一个矩形表示内存区域。倘若此时GC线程开始工作，那么紧接着开始的就是标记阶段了。此阶段与标记/清除算法的标记阶段是一样一样的，我们看标记阶段过后对象的状态，如下图。
没什么可解释的，接下来，便应该是整理阶段了。我们来看当整理阶段处理完以后，内存的布局是如何的，如下图。
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
不难看出，标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价，可谓是一举两得，一箭双雕，一石两鸟，一。。。。一女两男？
不过任何算法都会有其缺点，标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。
4、copying算法(Coping Collector) 复制
我们首先一起来看一下复制算法的做法，复制算法将内存划分为两个区间，在任意时间点，所有动态分配的对象都只能分配在其中一个区间（称为活动区间），而另外一个区间（称为空闲区间）则是空闲的。
当有效内存空间耗尽时，JVM将暂停程序运行，开启复制算法GC线程。接下来GC线程会将活动区间内的存活对象，全部复制到空闲区间，且严格按照内存地址依次排列，与此同时，GC线程将更新存活对象的内存引用地址指向新的内存地址。
此时，空闲区间已经与活动区间交换，而垃圾对象现在已经全部留在了原来的活动区间，也就是现在的空闲区间。事实上，在活动区间转换为空间区间的同时，垃圾对象已经被一次性全部回收。
听起来复杂吗？
其实一点也不复杂，有了上一章的基础，相信各位理解这个算法不会费太多力气。LZ给各位绘制一幅图来说明问题，如下所示。
其实这个图依然是上一章的例子，只不过此时内存被复制算法分成了两部分，下面我们看下当复制算法的GC线程处理之后，两个区域会变成什么样子，如下所示。
可以看到，1和4号对象被清除了，而2、3、5、6号对象则是规则的排列在刚才的空闲区间，也就是现在的活动区间之内。此时左半部分已经变成了空闲区间，不难想象，在下一次GC之后，左边将会再次变成活动区间。
很明显，复制算法弥补了标记/清除算法中，内存布局混乱的缺点。不过与此同时，它的缺点也是相当明显的。
1、它浪费了一半的内存，这太要命了。
2、如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。
所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。
算法总结
这里LZ给各位总结一下三个算法的共同点以及它们各自的优势劣势，让各位对比一下，想必会更加清晰。
它们的共同点主要有以下两点。
1、三个算法都基于根搜索算法去判断一个对象是否应该被回收，而支撑根搜索算法可以正常工作的理论依据，就是语法中变量作用域的相关内容。因此，要想防止内存泄露，最根本的办法就是掌握好变量作用域，而不应该使用前面内存管理杂谈一章中所提到的C/C++式内存管理方式。
2、在GC线程开启时，或者说GC过程开始时，它们都要暂停应用程序（stop the world）。
它们的区别LZ按照下面几点来给各位展示。（>表示前者要优于后者，=表示两者效果一样）
效率：复制算法>标记/整理算法>标记/清除算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法=标记/整理算法>标记/清除算法。
内存利用率：标记/整理算法=标记/清除算法>复制算法。
可以看到标记/清除算法是比较落后的算法了，但是后两种算法却是在此基础上建立的，俗话说“吃水不忘挖井人”，因此各位也莫要忘记了标记/清除这一算法前辈。而且，在某些时候，标记/清除也会有用武之地。
5、分代搜集算法
stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象，这增加了程序等待时间，这是coping算法低效的原因。在程序设计中有这样的规律：多数对象存在的时间比较短，少数的存在时间比较长。因此，generation算法将堆分成两个或多个，每个子堆作为对象的一代 (generation)。由于多数对象存在的时间比较短，随着程序丢弃不使用的对象，垃圾收集器将从最年轻的子堆中收集这些对象。在分代式的垃圾收集器运行后，上次运行存活下来的对象移到下一最高代的子堆中，由于老一代的子堆不会经常被回收，因而节省了时间。
对象分类
分代搜集算法是针对对象的不同特性，而使用适合的算法，这里面并没有实际上的新算法产生。与其说分代搜集算法是第四个算法，不如说它是对前三个算法的实际应用。
首先我们来探讨一下对象的不同特性，接下来LZ和各位来一起给这些对象选择GC算法。
内存中的对象按照生命周期的长短大致可以分为三种，以下命名均为LZ个人的命名。
1、夭折对象：朝生夕灭的对象，通俗点讲就是活不了多久就得死的对象。
例子：某一个方法的局域变量、循环内的临时变量等等。
2、老不死对象：这类对象一般活的比较久，岁数很大还不死，但归根结底，老不死对象也几乎早晚要死的，但也只是几乎而已。
例子：缓存对象、数据库连接对象、单例对象（单例模式）等等。
3、不灭对象：此类对象一般一旦出生就几乎不死了，它们几乎会一直永生不灭，记得，只是几乎不灭而已。
例子：String池中的对象（享元模式）、加载过的类信息等等。
对象对应的内存区域
还记得前面介绍内存管理时，JVM对内存的划分吗？
我们将上面三种对象对应到内存区域当中，就是夭折对象和老不死对象都在JAVA堆，而不灭对象在方法区。
之前的一章中我们就已经说过，对于JAVA堆，JVM规范要求必须实现GC，因而对于夭折对象和老不死对象来说，死几乎是必然的结局，但也只是几乎，还是难免会有一些对象会一直存活到应用结束。然而JVM规范对方法区的GC并不做要求，所以假设一个JVM实现没有对方法区实现GC，那么不灭对象就是真的不灭对象了。
由于不灭对象的生命周期过长，因此分代搜集算法就是针对的JAVA堆而设计的，也就是针对夭折对象和老不死对象。
JAVA堆的对象回收（夭折对象和老不死对象）
有了以上分析，我们来看看分代搜集算法如何处理JAVA堆的内存回收的，也就是夭折对象与老不死对象的回收。
夭折对象：这类对象朝生夕灭，存活时间短，还记得复制算法的使用要求吗？那就是对象存活率不能太高，因此夭折对象是最适合使用复制算法的。
小疑问：50%内存的浪费怎么办？
答疑：因为夭折对象一般存活率较低，因此可以不使用50%的内存作为空闲，一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的活动区间与另外80%中存活的对象转移到10%的空闲区间，接下来，将之前90%的内存全部释放，以此类推。
为了让各位更加清楚的看出来这个GC流程，LZ给出下面图示。
图中标注了三个区域中在各个阶段，各自内存的情况。相信看着图，它的GC流程已经不难理解了。
不过有两点LZ需要提一下，第一点是使用这样的方式，我们只浪费了10%的内存，这个是可以接受的，因为我们换来了内存的整齐排列与GC速度。第二点是，这个策略的前提是，每次存活的对象占用的内存不能超过这10%的大小，一旦超过，多出的对象将无法复制。
为了解决上面的意外情况，也就是存活对象占用的内存太大时的情况，高手们将JAVA堆分成两部分来处理，上述三个区域则是第一部分，称为新生代或者年轻代。而余下的一部分，专门存放老不死对象的则称为年老代。
是不是很贴切的名字呢？下面我们看看老不死对象的处理方式。
老不死对象：这一类对象存活率非常高，因为它们大多是从新生代转过来的。就像人一样，活的年月久了，就变成老不死了。
通常情况下，以下两种情况发生的时候，对象会从新生代区域转到年老带区域。
1、在新生代里的每一个对象，都会有一个年龄，当这些对象的年龄到达一定程度时（年龄就是熬过的GC次数，每次GC如果对象存活下来，则年龄加1），则会被转到年老代，而这个转入年老代的年龄值，一般在JVM中是可以设置的。
2、在新生代存活对象占用的内存超过10%时，则多余的对象会放入年老代。这种时候，年老代就是新生代的“备用仓库”。
针对老不死对象的特性，显然不再适合使用复制算法，因为它的存活率太高，而且不要忘了，如果年老代再使用复制算法，它可是没有备用仓库的。因此一般针对老不死对象只能采用标记/整理或者标记/清除算法。
方法区的对象回收（不灭对象）
以上两种情况已经解决了GC的大部分问题，因为JAVA堆是GC的主要关注对象，而以上也已经包含了分代搜集算法的全部内容，接下来对于不灭对象的回收，已经不属于分代搜集算法的内容。
不灭对象存在于方法区，在我们常用的hotspot虚拟机（JDK默认的JVM）中，方法区也被亲切的称为永久代，又是一个很贴切的名字不是吗？
其实在很久很久以前，是不存在永久代的。当时永久代与年老代都存放在一起，里面包含了JAVA类的实例信息以及类信息。但是后来发现，对于类信息的卸载几乎很少发生，因此便将二者分离开来。幸运的是，这样做确实提高了不少性能。于是永久代便被拆分出来了。
这一部分区域的GC与年老代采用相似的方法，由于都没有“备用仓库”，二者都是只能使用标记/清除和标记/整理算法。
回收的时机
JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。因此GC按照回收的区域又分了两种类型，一种是普通GC（minor GC），一种是全局GC（major GC or Full GC），它们所针对的区域如下。
普通GC（minor GC）：只针对新生代区域的GC。
全局GC（major GC or Full GC）：针对年老代的GC，偶尔伴随对新生代的GC以及对永久代的GC。
由于年老代与永久代相对来说GC效果不好，而且二者的内存使用增长速度也慢，因此一般情况下，需要经过好几次普通GC，才会触发一次全局GC。
三、垃圾收集器：
通俗的讲，使用编程语言将算法实现出来，产生的程序就是垃圾搜集器了。既然谈到了编程语言的实现，那么在讨论垃圾搜集器的时候，就已经涉及到具体的虚拟机实现了。
或许有不少做JAVA开发的猿友还不知道，我们平时使用的JDK中，默认的JVM是hotspot，换句话说，我们大部分时候使用的JVM都是hotspot的实现版本，因此，本次LZ讨论垃圾搜集器都是基于hotspot版JVM来进行的，请各位猿友要知晓这一点。
更直观的，我们可以在我们平时开发的机子上，输入java -version来查看JVM的版本，相信大部分猿友对这个命令都不陌生吧，LZ的机子截图如下。
垃圾搜集器的分类
上面我们已经提到，垃圾搜集器实际就是算法的编程语言实现。既然牵扯到编程语言，那么必然离不开线程，而且我们在前面讲解算法的时候也一直假设是一条GC线程在做着GC的事情。
因此，垃圾搜集器大致分为以下三类。
串行搜集器（serial collector）：它只有一条GC线程，且就像前面说的，它在运行的时候需要暂停用户程序（stop the world）。
并行搜集器（parallel collector）：它有多条GC线程，且它也需要暂停用户程序（stop the world）。
并发搜集器（concurrent collector）：它有一条或多条GC线程，且它需要在部分阶段暂停用户程序（stop the world），部分阶段与用户程序并发执行。
并发（concurrent）与并行（parallel）
看完上面的定义，相信有一部分猿友已经蒙了，一会单线程，一会多线程，一会串行，一会并行，一会并发，这都神马玩意？
单线程和多线程就不必多说了，这个很好理解，串行与并行也比较好理解，难于分辨的就是并行（parallel）与并发（concurrent）。
对于很多有关并发的解释，LZ觉得有一个最贴切。它是这么解释的，并发就是两个任务A和B需要相互独立的运行，并且A任务先开始后，B任务在A任务结束之前开始了。
并发本身是比较好理解的，那么它与并行的关系与区别是什么呢？
事实上，并行是并发的一种实现方式。LZ觉得这么说各位可能会更好理解，当然，并行并不是并发的唯一实现方式，还有一种就是我们所熟悉的时间片切换。也就是A任务执行一会，B任务执行一会，交替执行。
并行必须在多核多处理器或者分布式系统（本质还是多核多处理器）的前提下才能发生，而交替执行或者说时间片切换是在单核的处理器上发生的。
hotspot中的垃圾搜集器
我们上面已经简单探讨了垃圾搜集器的分类，在hotspotJVM中，每一个种类的垃圾搜集器都有对应的实现，如下。
串行搜集器的实现：serial（用于新生代，采用复制算法）、serial old（用于年老代，采用标记/整理算法）
并行搜集器的实现：ParNew（用于新生代，采用复制算法）、Parallel Scavenge（用于新生代，采用复制算法）、Parallel old（用于年老代，采用标记/整理算法）
并发搜集器的实现：concurrent mark sweep[CMS]（用于年老代，采用标记/清除算法）
可以看到，上面每一种垃圾搜集器都是针对不同内存区域所设计的，因为它们采用的算法不同，凡是用于新生代的都是使用的复制算法，而用于年老代的都是使用的标记/清除或者标记/整理算法。
在实际应用中，我们需要给JVM的新生代和年老代分别选择垃圾搜集器，可以看到无论是新生代还是年老代都分别有三种实现，换句话说，我们应该有3*3=9种选择。但是，事实并非如此。
事实上，这六种垃圾搜集器只有六种选择，因为有的垃圾搜集器由于具体实现的方式等一系列原因无法在一起工作，如下图。
针对上图，红的就是串行搜集器，绿的是并行搜集器，唯一一个黄的是并发搜集器。上面三个是新生代的搜集器，下面三个是年老代的搜集器。两者之间有连线，则表示两者可以配合工作。
这六种组合并没有说哪个组合最强，哪个组合最弱，还是那句话，只有最合适的，没有最好的。因此这就需要我们对每一种组合有一定的认识，才能在使用的时候选择更适合的垃圾搜集器
关于垃圾搜集器：JVM内存管理------垃圾搜集器精解（让你在垃圾搜集器的世界里耍的游刃有余） - 左潇龙 - 博客园、JVM内存管理------垃圾搜集器参数精解 - 左潇龙 - 博客园
五、finalize()方法
在JVM垃圾回收器收集一个对象之前，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止该对象心释放资源，这个方法就是finalize（）。它的原型为：
protected void finalize() throws Throwable
在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。
之所以要使用finalize()，是存在着垃圾回收器不能处理的特殊情况。假定你的对象（并非使用new方法）获得了一块“特殊”的内存区域，由于垃圾回收器只知道那些显示地经由new分配的内存空间，所以它不知道该如何释放这块“特殊”的内存区域，那么这个时候java允许在类中定义一个由finalize()方法。
特殊的区域例如：1）由于在分配内存的时候可能采用了类似 C语言的做法，而非JAVA的通常new做法。这种情况主要发生在native method中，比如native method调用了C/C++方法malloc()函数系列来分配存储空间，但是除非调用free()函数，否则这些内存空间将不会得到释放，那么这个时候就可能造成内存泄漏。但是由于free()方法是在C/C++中的函数，所以finalize()中可以用本地方法来调用它。以释放这些“特殊”的内存空间。2）又或者打开的文件资源，这些资源不属于垃圾回收器的回收范围。
换言之，finalize()的主要用途是释放一些其他做法开辟的内存空间，以及做一些清理工作。因为在JAVA中并没有提够像“析构”函数或者类似概念的函数，要做一些类似清理工作的时候，必须自己动手创建一个执行清理工作的普通方法，也就是override Object这个类中的finalize()方法。例如，假设某一个对象在创建过程中会将自己绘制到屏幕上，如果不是明确地从屏幕上将其擦出，它可能永远都不会被清理。如果在finalize()加入某一种擦除功能，当GC工作时，finalize()得到了调用，图像就会被擦除。要是GC没有发生，那么这个图像就会
被一直保存下来。
一旦垃圾回收器准备好释放对象占用的存储空间，首先会去调用finalize()方法进行一些必要的清理工作。只有到下一次再进行垃圾回收动作的时候，才会真正释放这个对象所占用的内存空间。
在普通的清除工作中，为清除一个对象，那个对象的用户必须在希望进行清除的地点调用一个清除方法。这与C++"析构函数"的概念稍有抵触。在C++中，所有对象都会破坏（清除）。或者换句话说，所有对象都"应该"破坏。若将C++对象创建成一个本地对象，比如在堆栈中创建（在Java中是不可能的，Java都在堆中），那么清除或破坏工作就会在"结束花括号"所代表的、创建这个对象的作用域的末尾进行。若对象是用new创建的（类似于Java），那么当程序员调用C++的 delete命令时（Java没有这个命令），就会调用相应的析构函数。若程序员忘记了，那么永远不会调用析构函数，我们最终得到的将是一个内存"漏洞"，另外还包括对象的其他部分永远不会得到清除。
相反，Java不允许我们创建本地（局部）对象--无论如何都要使用new。但在Java中，没有"delete"命令来释放对象，因为垃圾回收器会帮助我们自动释放存储空间。所以如果站在比较简化的立场，我们可以说正是由于存在垃圾回收机制，所以Java没有析构函数。然而，随着以后学习的深入，就会知道垃圾收集器的存在并不能完全消除对析构函数的需要，或者说不能消除对析构函数代表的那种机制的需要（原因见下一段。另外finalize()函数是在垃圾回收器准备释放对象占用的存储空间的时候被调用的，绝对不能直接调用finalize()，所以应尽量避免用它）。若希望执行除释放存储空间之外的其他某种形式的清除工作，仍然必须调用Java中的一个方法。它等价于C++的析构函数，只是没后者方便。
在C++中所有的对象运用delete()一定会被销毁，而JAVA里的对象并非总会被垃圾回收器回收。In another word, 1 对象可能不被垃圾回收，2 垃圾回收并不等于“析构”，3 垃圾回收只与内存有关。也就是说，并不是如果一个对象不再被使用，是不是要在finalize()中释放这个对象中含有的其它对象呢？不是的。因为无论对象是如何创建的，垃圾回收器都会负责释放那些对象占有的内存。
六、触发主GC（Garbage Collector）的条件
JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC:
1)当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。
2)Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。
七、减少GC开销的措施
根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串
由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如Int,Long,就不用Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。
八、关于垃圾回收的几点补充
经过上述的说明，可以发现垃圾回收有以下的几个特点：
（1）垃圾收集发生的不可预知性：由于实现了不同的垃圾回收算法和采用了不同的收集机制，所以它有可能是定时发生，有可能是当出现系统空闲CPU资源时发生，也有可能是和原始的垃圾收集一样，等到内存消耗出现极限时发生，这与垃圾收集器的选择和具体的设置都有关系。
（2）垃圾收集的精确性：主要包括2 个方面：（a）垃圾收集器能够精确标记活着的对象；（b）垃圾收集器能够精确地定位对象之间的引用关系。前者是完全地回收所有废弃对象的前提，否则就可能造成内存泄漏。而后者则是实现归并和复制等算法的必要条件。所有不可达对象都能够可靠地得到回收，所有对象都能够重新分配，允许对象的复制和对象内存的缩并，这样就有效地防止内存的支离破碎。
（3）现在有许多种不同的垃圾收集器，每种有其算法且其表现各异，既有当垃圾收集开始时就停止应用程序的运行，又有当垃圾收集开始时也允许应用程序的线程运行，还有在同一时间垃圾收集多线程运行。
（4）垃圾收集的实现和具体的JVM 以及JVM的内存模型有非常紧密的关系。不同的JVM 可能采用不同的垃圾收集，而JVM 的内存模型决定着该JVM可以采用哪些类型垃圾收集。现在，HotSpot 系列JVM中的内存系统都采用先进的面向对象的框架设计，这使得该系列JVM都可以采用最先进的垃圾收集。
（5）随着技术的发展，现代垃圾收集技术提供许多可选的垃圾收集器，而且在配置每种收集器的时候又可以设置不同的参数，这就使得根据不同的应用环境获得最优的应用性能成为可能。
针对以上特点，我们在使用的时候要注意：
（1）不要试图去假定垃圾收集发生的时间，这一切都是未知的。比如，方法中的一个临时对象在方法调用完毕后就变成了无用对象，这个时候它的内存就可以被释放。
（2）Java中提供了一些和垃圾收集打交道的类，而且提供了一种强行执行垃圾收集的方法--调用System.gc()，但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集，它只不过会向JVM发出这样一个申请，到底是否真正执行垃圾收集，一切都是个未知数。
（3）挑选适合自己的垃圾收集器。一般来说，如果系统没有特殊和苛刻的性能要求，可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器，比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置，有比较多的闲置资源，可以考虑使用并行标记/清除收集器。
（4）关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的，不要让自己的一个小错误导致内存出现大漏洞。
（5）尽早释放无用对象的引用。大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域(scope)后，自动设置为null，暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。
参考：
