UML软件工程组织

深入浅出谈垃圾的回收—Java 堆的管理 (2)
来自:http://www.javaresearch.org
5、generation算法(generational collector)

stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象,这增加了程序等待时间,这是coping算法低效的原因。在程序设计中有这样的规律:多数对象存在的时间比较短,少数的存在时间比较长。因此,generation算法将堆分成两个或多个,每个子堆作为对象的一代(generation)。由于多数对象存在的时间比较短,随着程序丢弃不使用的对象,垃圾收集器将从最年轻的子堆中收集这些对象。在分代式的垃圾收集器运行后,上次运行存活下来的对象移到下一最高代的子堆中,由于老一代的子堆不会经常被回收,因而节省了时间。

6、adaptive算法(adaptive collector)

在特定的情况下,一些垃圾收集算法会优于其它算法。基于adaptive算法的垃圾收集器就是监控当前堆的使用情况,并将选择适当算法的垃圾收集器。

透视Java垃圾回收

1、命令行参数透视垃圾收集器的运行

使用system.gc()可以不管Jvm使用的是哪一种垃圾回收的算法,都可以请求Java的垃圾回收。在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况,它的格式如下:

Java -verbosegc classfile可以看个例子:


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()。它的原型为:


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 的破坏器,只是没后者方便。下面这个例子向大家展示了垃圾收集所经历的过程,并对前面的陈述进行了总结。

 

 

版权所有:UML软件工程组织