Java的垃圾回收之算法Word文档格式.docx
《Java的垃圾回收之算法Word文档格式.docx》由会员分享，可在线阅读，更多相关《Java的垃圾回收之算法Word文档格式.docx（12页珍藏版）》请在冰豆网上搜索。
在用Java语言编程的时候，靠垃圾收集机制可大大缩短时间。
其次是它保护程序的完整性，垃圾收集是Java语言安全性策略的一个重要部份。
垃圾收集的一个潜在的缺点是它的开销影响程序性能。
Java虚拟机必须追踪运行程序中有用的对象，而且最终释放没用的对象。
这一个过程需要花费处理器的时间。
其次垃圾收集算法的不完备性，早先采用的某些垃圾收集算法就不能保证100%收集到所有的废弃内存。
当然随着垃圾收集算法的不断改进以及软硬件运行效率的不断提升，这些问题都可以迎刃而解。
垃圾收集的算法分析
Java语言规范没有明确地说明JVM使用哪种垃圾回收算法，但是任何一种垃圾收集算法一般要做2件基本的事情：
（1）发现无用信息对象；
（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。
大多数垃圾回收算法使用了根集（rootset）这个概念；
所谓根集就量正在执行的Java程序可以访问的引用变量的集合（包括局部变量、参数、类变量），程序可以使用引用变量访问对象的属性和调用对象的方法。
垃圾收集首选需要确定从根开始哪些是可达的和哪些是不可达的，从根集可达的对象都是活动对象，它们不能作为垃圾被回收，这也包括从根集间接可达的对象。
而根集通过任意路径不可达的对象符合垃圾收集的条件，应该被回收。
下面介绍几个常用的算法。
1、引用计数法（ReferenceCountingCollector）
引用计数法是唯一没有使用根集的垃圾回收的法，该算法使用引用计数器来区分存活对象和不再使用的对象。
一般来说，堆中的每个对象对应一个引用计数器。
当每一次创建一个对象并赋给一个变量时，引用计数器置为1。
当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后（该对象丢弃不再使用），引用计数器减1，一旦引用计数器为0，对象就满足了垃圾收集的条件。
基于引用计数器的垃圾收集器运行较快，不会长时间中断程序执行，适宜地必须实时运行的程序。
但引用计数器增加了程序执行的开销，因为每次对象赋给新的变量，计数器加1，而每次现有对象出了作用域生，计数器减1。
2、tracing算法（TracingCollector）
tracing算法是为了解决引用计数法的问题而提出，它使用了根集的概念。
基于tracing算法的垃圾收集器从根集开始扫描，识别出哪些对象可达，哪些对象不可达，并用某种方式标记可达对象，例如对每个可达对象设置一个或多个位。
在扫描识别过程中，基于tracing算法的垃圾收集也称为标记和清除（mark-and-sweep）垃圾收集器.
3、compacting算法（CompactingCollector）
为了解决堆碎片问题，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的过程中，算法将所有的对象移到堆的一端，堆的另一端就变成了一个相邻的空闲内存区，收集器会对它移动的所有对象的所有引用进行更新，使得这些引用在新的位置能识别原来的对象。
在基于Compacting算法的收集器的实现中，一般增加句柄和句柄表。
4、copying算法（CopingCollector）
该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。
它开始时把堆分成一个对象面和多个空闲面，程序从对象面为对象分配空间，当对象满了，基于coping算法的垃圾收集就从根集中扫描活动对象，并将每个活动对象复制到空闲面（使得活动对象所占的内存之间没有空闲洞），这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。
一种典型的基于coping算法的垃圾回收是stop-and-copy算法，它将堆分成对象面和空闲区域面，在对象面与空闲区域面的切换过程中，程序暂停执行。
5、generation算法（GenerationalCollector）
stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象，这增加了程序等待时间，这是coping算法低效的原因。
在程序设计中有这样的规律：
多数对象存在的时间比较短，少数的存在时间比较长。
因此，generation算法将堆分成两个或多个，每个子堆作为对象的一代（generation）。
由于多数对象存在的时间比较短，随着程序丢弃不使用的对象，垃圾收集器将从最年轻的子堆中收集这些对象。
在分代式的垃圾收集器运行后，上次运行存活下来的对象移到下一最高代的子堆中，由于老一代的子堆不会经常被回收，因而节省了时间。
6、adaptive算法（AdaptiveCollector）
在特定的情况下，一些垃圾收集算法会优于其它算法。
基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。
透视Java垃圾回收
1、命令行参数透视垃圾收集器的运行
2、使用System.gc（）可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。
在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况，它的格式如下：
java-verbosegcclassfile
可以看个例子：
classTestGC
{
publicstaticvoidmain（String[]args）
newTestGC（）;
System.gc（）;
System.runFinalization（）;
}
在这个例子中，一个新的对象被创建，由于它没有使用，所以该对象迅速地变为可达，程序编译后，执行命令：
java-verbosegcTestGC后结果为：
[FullGC168K->
97K（1984K），0.0253873secs]
机器的环境为，Windows2000+JDK1.3.1，箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有168K-97K=71K的对象容量被回收，括号内的数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒（这个时间在每次执行的时候会有所不同）。
2、finalize方法透视垃圾收集器的运行
在JVM垃圾收集器收集一个对象之前，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止化该对象心释放资源，这个方法就是finalize（）。
它的原型为：
protectedvoidfinalize（）throwsThrowable
在finalize（）方法返回之后，对象消失，垃圾收集开始执行。
原型中的throwsThrowable表示它可以抛出任何类型的异常。
之所以要使用finalize（），是由于有时需要采取与Java的普通方法不同的一种方法，通过分配内存来做一些具有C风格的事情。
这主要可以通过"
固有方法"
来进行，它是从Java里调用非Java方法的一种方式。
C和C++是目前唯一获得固有方法支持的语言。
但由于它们能调用通过其他语言编写的子程序，所以能够有效地调用任何东西。
在非Java代码内部，也许能调用C的malloc（）系列函数，用它分配存储空间。
而且除非调用了free（），否则存储空间不会得到释放，从而造成内存"
漏洞"
的出现。
当然，free（）是一个C和C++函数，所以我们需要在finalize（）内部的一个固有方法中调用它。
也就是说我们不能过多地使用finalize（），它并不是进行普通清除工作的理想场所。
在普通的清除工作中，为清除一个对象，那个对象的用户必须在希望进行清除的地点调用一个清除方法。
这与C++"
破坏器"
的概念稍有抵触。
在C++中，所有对象都会破坏（清除）。
或者换句话说，所有对象都"
应该"
破坏。
若将C++对象创建成一个本地对象，比如在堆栈中创建（在Java中是不可能的），那么清除或破坏工作就会在"
结束花括号"
所代表的、创建这个对象的作用域的末尾进行。
若对象是用new创建的（类似于Java），那么当程序员调用C++的delete命令时（Java没有这个命令），就会调用相应的破坏器。
若程序员忘记了，那么永远不会调用破坏器，我们最终得到的将是一个内存"
，另外还包括对象的其他部分永远不会得到清除。
相反，Java不允许我们创建本地（局部）对象--无论如何都要使用new。
但在Java中，没有"
delete"
命令来释放对象，因为垃圾收集器会帮助我们自动释放存储空间。
所以如果站在比较简化的立场，我们可以说正是由于存在垃圾收集机制，所以Java没有破坏器。
然而，随着以后学习的深入，就会知道垃圾收集器的存在并不能完全消除对破坏器的需要，或者说不能消除对破坏器代表的那种机制的需要（而且绝对不能直接调用finalize（），所以应尽量避免用它）。
若希望执行除释放存储空间之外的其他某种形式的清除工作，仍然必须调用Java中的一个方法。
它等价于C++的破坏器，只是没后者方便。
下面这个例子向大家展示了垃圾收集所经历的过程，并对前面的陈述进行了总结。
classChair{
staticbooleangcrun=false;
staticbooleanf=false;
staticintcreated=0;
staticintfinalized=0;
inti;
Chair（）{
i=++created;
if（created==47）
System.out.println（"
Created47"
）;
protectedvoidfinalize（）{
if（!
gcrun）{
gcrun=true;
Beginningtofinalizeafter"
+created+"
Chairshavebeencreated"
if（i==47）{
FinalizingChair#47，"
+"
SettingflagtostopChaircreation"
f=true;
finalized++;
if（finalized>
=created）
All"
+finalized+"
finalized"
publicclassGarbage{
publicstaticvoidmain（String[]args）{
if（args.length==0）{
System.err.println（"
Usage:
\n"
+"
javaGarbagebefore\nor:
\n"
javaGarbageafter"
return;
while（!
Chair.f）{
newChair（）;
newString（"
Totakeupspace"
AfterallChairshavebeencreated:
totalcreated="
+Chair.created+
"
，totalfinalized="
+Chair.finalized）;
if（args[0].equals（"
before"
））{
gc（）:
"
runFinalization（）:
System.out.println（"
bye!
after"
））
System.runFinalizersOnExit（true）;
上面这个程序创建了许多Chair对象，而且在垃圾收集器开始运行后的某些时候，程序会停止创建Chair。
由于垃圾收集器可能在任何时间运行，所以我们不能准确知道它在何时启动。
因此，程序用一个名为gcrun的标记来指出垃圾收集器是否已经开始运行。
利用第二个标记f，Chair可告诉main（）它应停止对象的生成。
这两个标记都是在finalize（）内部设置的，它调用于垃圾收集期间。
另两个static变量--created以及finalized--分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作的对象数量。
最后，每个Chair都有它自己的（非static）inti，所以能跟踪了解它具体的编号是多少。
编号为47的Chair进行完收尾工作后，标记会设为true，最终结束Chair对象的创建过程。
关于垃圾收集的几点补充
经过上述的说明，可以发现垃圾回收有以下的几个特点：
（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，暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。
结束语
一般来说，Java开发人员可以不重视JVM中堆内存的分配和垃圾处理收集，但是，充分理解Java的这一特性可以让我们更有效地利用资源。
同时要注意finalize（）方法是Java的缺省机制，有时为确保对象资源的明确释放，可以编写自己的finalize方法。
升级会员 