JVM垃圾回收机制总结(6) ：透视Java的GC特性

来源：互联网发布：淘宝周点数编辑：程序博客网时间：2024/05/21 08:35

JVM垃圾回收机制总结(6) ：透视Java的GC特性

博客分类：

J2SE - JVM与CLASS

JVMJava算法CC++

全文转载： http://topic.csdn.net/u/20091211/12/c79a9293-fdd5-4f81-b18f-a4a29c8d9be2.html
作者： yang677888 (from CSDN)

1、使用 System.gc() 可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求 Java的垃圾回收。在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况，它的格式：java -verbosegc classfile

Java代码

class TestGC {
　 public staticvoid main(String[] args) {
　　new TestGC();
　　 System.gc();
　　 System.runFinalization();
}
}
class TestGC {
　 public staticvoid main(String[] args) {
　　new TestGC();
　　 System.gc();
　　System.runFinalization();
　}
}

class TestGC {     　 public static void main(String[] args) {     　  　new TestGC();     　　  System.gc();     　　  System.runFinalization();       }    }      class TestGC {  　 public static void main(String[] args) {  　　new TestGC();  　　 System.gc();  　　System.runFinalization();  　}  }

在这个例子中，一个新的对象被创建，由于它没有使用，所以该对象迅速地变为可达，程序编译后，执行命令： java -verbosegc TestGC 后结果为：

[Full GC 168K->97K(1984K)， 0.0253873 secs]

　　机器的环境为，Windows 2000 + JDK1.3.1，箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有168K-97K=71K的对象容量被回收，括号内的数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒（这个时间在每次执行的时候会有所不同）。

2、 finalize方法透视垃圾收集器的运行

　　在JVM垃圾收集器收集一个对象之前，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止化该对象心释放资源，这个方法就是 finalize（）。它的原型为：
Java代码
1. protected void finalize() throws Throwable
　在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。

　之所以要使用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++的破坏器，只是没后者方便。

　　下面这个例子向大家展示了垃圾收集所经历的过程，并对前面的陈述进行了总结。

Java代码

package hr.test;
import java.util.Calendar;
class Chair {
static int created =0; //对象创建计数
static int finalized =0; //对象回收计数
//构造器
Chair(){
created++;
System.err.println("created "+created+"【"+Calendar.getInstance().get(Calendar.MINUTE)+"m "+Calendar.getInstance().get(Calendar.SECOND)+"s】");
}
//垃圾回收析构函数
protected void finalize() {
finalized++;
System.out.println("finalize "+finalized+"【"+Calendar.getInstance().get(Calendar.MINUTE)+"m "+Calendar.getInstance().get(Calendar.SECOND)+"s】");
}
}
public class Garbage {
public staticvoid main(String[] args) {
while(Chair.created!=10000) {
new Chair();//创建对象
}
while(true){
if(Chair.created==10000){
break;
}
}
}
}

package hr.test;    import java.util.Calendar;         class Chair {      static int created = 0; //对象创建计数      static int finalized = 0; //对象回收计数      //构造器      Chair(){          created++;          System.err.println("created "+created+"【"+Calendar.getInstance().get(Calendar.MINUTE)+"m "+Calendar.getInstance().get(Calendar.SECOND)+"s】");      }      //垃圾回收析构函数      protected void finalize() {          finalized++;          System.out.println("finalize "+finalized+"【"+Calendar.getInstance().get(Calendar.MINUTE)+"m "+Calendar.getInstance().get(Calendar.SECOND)+"s】");      }  }    public class Garbage {      public static void main(String[] args) {          while(Chair.created!=10000) {              new Chair();//创建对象          }          while(true){              if(Chair.created==10000){                  break;              }          }      }  }

　　上面这个程序创建了10000个Chair对象。但是在运行结果中发现，在累计循环创建到x个对象的时候，我们发现主线程被挂起，JVM开始运行垃圾回收程序。证据就是屏幕上开始打印出"final ..."。而且主线程被挂起的时间是不定的，有的时候我们甚至能在输出中看到半条"create.. "就开始打印"final ..."了。

　　经过上述的说明，可以发现垃圾回收有以下的几个特点：

　　（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方法。