程序员都知道“初始化”的重要性,但通常忘记清除的重要性。毕竟,谁需要来清除一个int 呢?但是对于
库来说,用完后简单地“释放”一个对象并非总是安全的。当然,Java 可用垃圾收集器回收由不再使用的对
象占据的内存。现在考虑一种非常特殊且不多见的情况。假定我们的对象分配了一个“特殊”内存区域,没
有使用new。垃圾收集器只知道释放那些由new 分配的内存,所以不知道如何释放对象的“特殊”内存。为
解决这个问题,Java 提供了一个名为finalize()的方法,可为我们的类定义它。在理想情况下,它的工作原
理应该是这样的:一旦垃圾收集器准备好释放对象占用的存储空间,它首先调用finalize(),而且只有在下
一次垃圾收集过程中,才会真正回收对象的内存。所以如果使用finalize(),就可以在垃圾收集期间进行一
些重要的清除或清扫工作。上面这段文字是Think in java 4.3 清除:收尾和垃圾收集 一章中的第一段.
主要是想看看大牛们对垃圾回收器的看法, 因此, 没有循证原版Think in java中是怎么样描述这个问题的.
当然, 这个问题也可能是由于jdk的版本引起的误差, 因此, 题目只是想吸引大家进来看看...呵呵请注意红字标明的部分, 我们可以看出, 作者(或者是翻译的误差? 这里就这么用用吧, 呵呵)认为: 垃圾回收器在运行时, 会首先调用对象的finalize方法, 在下一次垃圾回收器运行时, 释放该对象的内存.为了照顾各位的情绪, 我还是把问题先在这里描述一下吧, 测试代码在Garbage类中的两个System.gc()的位置, 那里也有些注释的.
* 我对jdk6.0_update_10的GC的运行机制的推测.
* 1. 收集需要回收的对象, 并以某种方式记录下来.
* 2. 调用上次记录在案的需要回收的对象的finalize方法.
* 3. 回收已经调用过finalize方法的需要回收的对象.
* 4. 将已经释放的对象从那个"记录"中移除.
* 下一次运行, 继续1-4的步骤.我下面引入程序代码(基本上是Think in java中的源代码, 对其中有些东西做了一点小的调整, 效果比较明显一点.):
1. Chair类, 我们就是用它来模拟垃圾的.package selfimpr.ThinkInJava.gc;public class Chair {
static boolean gcrun = false;
static boolean f = false;
static int created = 0;
static int finalized = 0;
int i;
Chair() {
i = ++created;
if(created == 35000)
System.out.println("Created 35000");
}
protected void finalize() {
//检测gc的第一次运行,gc第一次运行时调用finalize方法会触发并输出
if(!gcrun) {
gcrun = true;
System.out.println("Beginning to finalize after " +
created + " Chairs have been ced. ");
}
//监测收集编号i值为35000的Chair对象.
if(i==35000) {
System.out.println("Finalizing Chair #35000, " + "i" + i + " " + created +
"Setting flag to stop Chair creation");
//当i值为35000的Chair的对象被垃圾收集后, 将f设置为true, 结束创建.
f = true;
}
//记录销毁对象的数目
finalized ++;
if(finalized >= created-100)
System.out.println("All " + finalized + " finalized");
}
}
2. 主类, 控制程序监测GC运行package selfimpr.ThinkInJava.gc;public class Garbage { public static void main(String[] args) {
if(args.length == 0) {
System.err.println("Usage: \n" +
"java Garbage before\n or:\n" +
"java Garbage after");
return ;
}
//1. Chair.f为假时不断的创建Chair和String对象.
while(!Chair.f) {
new Chair();
new String("To take up space");
}
//结束创建活动后, 打印总共被创建了多少Chair对象.
//在这个过程中, JVM自动运行的垃圾回收回收了多少个Chair对象.
System.out.println("After all Chairs have been created:\n" +
"total created = " + Chair.created +
", total finalized = " + Chair.finalized);
if(args[0].equals("before")) {
System.out.println("gc():");
System.gc();
System.out.println("runFinalization():");
System.runFinalization();
}
//这个地方进行了改动, 下面这两行代码是新加的.
//这里我做了两次测试
/*
* 第一次, 调用一次System.gc();
* 第二次, 调用两次System.gc();
* 然而, 和Think in java的讲法不同, 我调用第一System.gc()的时候,
* 程序中没有释放的其他对象的finalize方法并没有被调用.
* 而我调用两次System.gc();所有没有被释放的对象的finalize方法都被调用了.
*
* 因此, 感觉至少在jdk6.0_update_10中, GC的运行是在第二次的时候,
* 才调用finalize方法并释放内存的.
*/
System.gc();
System.gc();
//被改动的代码结束
System.out.println("bye!");
if(args[0].equals("after"))
System.runFinalizersOnExit(true);
}}
库来说,用完后简单地“释放”一个对象并非总是安全的。当然,Java 可用垃圾收集器回收由不再使用的对
象占据的内存。现在考虑一种非常特殊且不多见的情况。假定我们的对象分配了一个“特殊”内存区域,没
有使用new。垃圾收集器只知道释放那些由new 分配的内存,所以不知道如何释放对象的“特殊”内存。为
解决这个问题,Java 提供了一个名为finalize()的方法,可为我们的类定义它。在理想情况下,它的工作原
理应该是这样的:一旦垃圾收集器准备好释放对象占用的存储空间,它首先调用finalize(),而且只有在下
一次垃圾收集过程中,才会真正回收对象的内存。所以如果使用finalize(),就可以在垃圾收集期间进行一
些重要的清除或清扫工作。上面这段文字是Think in java 4.3 清除:收尾和垃圾收集 一章中的第一段.
主要是想看看大牛们对垃圾回收器的看法, 因此, 没有循证原版Think in java中是怎么样描述这个问题的.
当然, 这个问题也可能是由于jdk的版本引起的误差, 因此, 题目只是想吸引大家进来看看...呵呵请注意红字标明的部分, 我们可以看出, 作者(或者是翻译的误差? 这里就这么用用吧, 呵呵)认为: 垃圾回收器在运行时, 会首先调用对象的finalize方法, 在下一次垃圾回收器运行时, 释放该对象的内存.为了照顾各位的情绪, 我还是把问题先在这里描述一下吧, 测试代码在Garbage类中的两个System.gc()的位置, 那里也有些注释的.
* 我对jdk6.0_update_10的GC的运行机制的推测.
* 1. 收集需要回收的对象, 并以某种方式记录下来.
* 2. 调用上次记录在案的需要回收的对象的finalize方法.
* 3. 回收已经调用过finalize方法的需要回收的对象.
* 4. 将已经释放的对象从那个"记录"中移除.
* 下一次运行, 继续1-4的步骤.我下面引入程序代码(基本上是Think in java中的源代码, 对其中有些东西做了一点小的调整, 效果比较明显一点.):
1. Chair类, 我们就是用它来模拟垃圾的.package selfimpr.ThinkInJava.gc;public class Chair {
static boolean gcrun = false;
static boolean f = false;
static int created = 0;
static int finalized = 0;
int i;
Chair() {
i = ++created;
if(created == 35000)
System.out.println("Created 35000");
}
protected void finalize() {
//检测gc的第一次运行,gc第一次运行时调用finalize方法会触发并输出
if(!gcrun) {
gcrun = true;
System.out.println("Beginning to finalize after " +
created + " Chairs have been ced. ");
}
//监测收集编号i值为35000的Chair对象.
if(i==35000) {
System.out.println("Finalizing Chair #35000, " + "i" + i + " " + created +
"Setting flag to stop Chair creation");
//当i值为35000的Chair的对象被垃圾收集后, 将f设置为true, 结束创建.
f = true;
}
//记录销毁对象的数目
finalized ++;
if(finalized >= created-100)
System.out.println("All " + finalized + " finalized");
}
}
2. 主类, 控制程序监测GC运行package selfimpr.ThinkInJava.gc;public class Garbage { public static void main(String[] args) {
if(args.length == 0) {
System.err.println("Usage: \n" +
"java Garbage before\n or:\n" +
"java Garbage after");
return ;
}
//1. Chair.f为假时不断的创建Chair和String对象.
while(!Chair.f) {
new Chair();
new String("To take up space");
}
//结束创建活动后, 打印总共被创建了多少Chair对象.
//在这个过程中, JVM自动运行的垃圾回收回收了多少个Chair对象.
System.out.println("After all Chairs have been created:\n" +
"total created = " + Chair.created +
", total finalized = " + Chair.finalized);
if(args[0].equals("before")) {
System.out.println("gc():");
System.gc();
System.out.println("runFinalization():");
System.runFinalization();
}
//这个地方进行了改动, 下面这两行代码是新加的.
//这里我做了两次测试
/*
* 第一次, 调用一次System.gc();
* 第二次, 调用两次System.gc();
* 然而, 和Think in java的讲法不同, 我调用第一System.gc()的时候,
* 程序中没有释放的其他对象的finalize方法并没有被调用.
* 而我调用两次System.gc();所有没有被释放的对象的finalize方法都被调用了.
*
* 因此, 感觉至少在jdk6.0_update_10中, GC的运行是在第二次的时候,
* 才调用finalize方法并释放内存的.
*/
System.gc();
System.gc();
//被改动的代码结束
System.out.println("bye!");
if(args[0].equals("after"))
System.runFinalizersOnExit(true);
}}
{
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++的破坏器,只是没后者方便。 下面这个例子向大家展示了垃圾收集所经历的过程,并对前面的陈述进行了总结。 class Chair {
static boolean gcrun = false;
static boolean f = false;
static int created = 0;
static int finalized = 0;
int i;
Chair() {
i = ++created;
if(created == 47)
System.out.println("Created 47");
}
protected void finalize() {
if(!gcrun) {
gcrun = true;
System.out.println("Beginning to finalize after " + created + " Chairs have been created");
}
if(i == 47) {
System.out.println("Finalizing Chair #47, " +"Setting flag to stop Chair creation");
f = true;
}
finalized++;
if(finalized >= created)
System.out.println("All " + finalized + " finalized");
}
} public class Garbage {
public static void main(String[] args) {
if(args.length == 0) {
System.err.println("Usage: \n" + "java Garbage before\n or:\n" + "java Garbage after");
return;
}
while(!Chair.f) {
new Chair();
new String("To take up space");
}
System.out.println("After all Chairs have been created:\n" + "total created = " + Chair.created +
", total finalized = " + Chair.finalized);
if(args[0].equals("before")) {
System.out.println("gc():");
System.gc();
System.out.println("runFinalization():");
System.runFinalization();
}
System.out.println("bye!");
if(args[0].equals("after"))
System.runFinalizersOnExit(true);
}
}
上面这个程序创建了许多Chair对象,而且在垃圾收集器开始运行后的某些时候,程序会停止创建Chair。由于垃圾收集器可能在任何时间运行,所以我们不能准确知道它在何时启动。因此,程序用一个名为gcrun的标记来指出垃圾收集器是否已经开始运行。利用第二个标记f,Chair可告诉main()它应停止对象的生成。这两个标记都是在finalize()内部设置的,它调用于垃圾收集期间。另两个static变量--created以及finalized--分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作的对象数量。最后,每个Chair都有它自己的(非static)int i,所以能跟踪了解它具体的编号是多少。编号为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方法。
首先,上面说的有在"理想状态"下
再一个,建议LZ看第四版的Thank in Java 吧
上面有讲到,要不寄希望于这个方法的
因为你根本不知道系统什么时候会清理垃圾
甚至于一直到程序执行完毕,都不会执行这个方法
如果直的想清理资源
建议使用try() finally()块进行清理
一直都是知道java的gc 能回收对象,但还不知道这里面有这么多东西啊。