对象生存还是死亡?
在可达性分析算法中判定为不可达的对象,也不是"非死不可的"
的,这时候它们暂时还处于“缓刑”
阶段,要真正宣告一个对象死亡,至少要经历两次标记过程。
如果对象在进行可达性分析后发现没有与GC Roots
相连接的引用链,那它将会第一次被标记,随后进行一次筛选,筛选的条件是此对象是否有必要执行finalize()
方法。 假如对象没有覆盖(实现)finalize()
方法,或者finalize()
方法已经被虚拟机调用过,那么虚拟机将这两种情况都视为没有必要执行
。
如果这个对象被判定为确有必要执行finalize()
方法,那么该对象会被放置在一个名为F-Queue
的队列中,并在稍后在一条由虚拟机自动建立的、低调度优先级的Finalizer
线程去执行它们的finalize()
方法,
这里所说的执行
是指虚拟机会触发这个方法开始运行,但不承诺一定会等待它运行结束, 这样做的原因是,如果某个对象的finalize()
方法执行缓慢吧,或者更极端的发生了死循环,将很可能导致F-Queue
队列中的其他对象永久处于等待,甚至导致整个回收子系统的崩溃。
finalize()
方法是对象逃脱死亡命运的最后一次机会,稍后收集器将对F-Queue
中的对象进行第二次小规模的标记,如果对象要在finalize()
中成功拯救自己,只需要重新与引用链上的任何一个对象建立关联即可,比如把自己(this关键字)赋值给某个变量或者对象的成员变量,那在第二次标记时,它将被移出即将回收
的集合;如果这时候对象还没有逃脱,那基本上它真的要被回收了。
一起看下下面的demo:
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public void isAlive() {
System.out.println("yes, i am still alive .");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize method executed");
// 重新添加到引用链上
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC();
// 对象一次成功拯救自己
SAVE_HOOK = null;
System.gc();
// 因为Finalize方法优先级很低,暂停0.5秒,用来等待它
Thread.sleep(500);
if(SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no , i am dead .");
}
// 下面这段代码与上面的完全相同,这次自救失败
SAVE_HOOK = null;
System.gc();
// 因为Finalize方法优先级很低,暂停0.5秒,用来等待它
Thread.sleep(500);
if(SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no , i am dead .");
}
}
}
运行结果:
finalize method executed
yes, i am still alive .
no , i am dead .
从上面的代码和运行结果可以看到,SAVE_HOOK
对象的finalize()
方法确实被垃圾收集器触发过,并且在被收集前成功逃脱了。
另一个值得注意的地方就是,代码中有两段完全一样的地方,结果却是一次逃脱成功,一次失败了,这是因为任何一个对象的finalize()
方法都只会被系统自动调用一次,如果对象面临下一次回收,它的finalize()
方法不会被再次执行,因此第二段代码的自救行动失败了。
finalize()
方法无法等同于C/C++
中的析构函数,而是Java诞生的时候,为了让C/C++
程序员更容易接受Java的一种妥协,它的运行代价高昂,不确定性大,无法保证各个对象的调用顺序,如今已经被官方明确声明为不推荐使用的语法,
有些教材中描述它适合做关闭外部资源
之类的清理工作,这完全是对finalize()
方法用途的一种自我安慰。finalize()
能做的所有工作,使用try-finally
或者其他方式都可以做的更好,更及时,所以强烈不建议大家去使用这个方法。