对象已死吗¶
堆里面存放着几乎所有的对象实例,垃圾收集器在对堆进行回收前,第一件事就是要确定这些对象之中哪些还“存活”着,哪些已经“死去”(即不可能再被任何途径使用的对象)
1. 引用计数算法(Reference Counting)¶
给对象添加一个引用计数器,每当有一个地方引用它时,计数器就加 1;当引用失效时,计数器值就减 1;计数器值为 0 的对象不可能再被使用。
缺点:很难解决对象之间互相循环引用的问题
在大部分情况下可以使用,但是虚拟机并没有使用这一算法。
2. 可达性分析算法(Reachability Analysis)¶
基本思想:通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用连,当一个对象到GC Roots没有任何引用链相连的时候,则证明该对象是不可用的。
Java语言中使用GC Roots的对象包括以下几种: - 虚拟机栈(栈帧中的本地变量表)中引用的对象 - 方法区中类静态属性引用的对象 - 方法区中常量引用的对象 - 本地方法栈中JNI(Native方法)引用的对象
3. 再谈引用¶
对象的存货都与“引用”有关。在JDK1.2之前,Java中的引用很传统:reference类型的数值代表的是另一块内存的其实地址,就称这块内存代表着一个引用。在这种定义下,一个对象只有引用或者没有被引用两种状态,对于描述一些可用可不用的对象就显得无能为力。
在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)4种,这四种引用强度依次减弱。
-
强引用:类似 "Object obj = new Object();",只要强引用还存在,垃圾收集器永远不会回收掉被引用的对象。
-
软引用:描述一些还有用但并非必须的对象。对于软引用关联着的对象,在系统将要发生内存溢出异常之前,将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存,才会抛出内存溢出异常。在JDK1.2之后,提供了SoftReference类来实现软引用。
-
弱引用:描述非必需对象,但是它的强度比软引用更弱一些,被软引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。在JDK1.2之后,提供了WeakReference类来实现弱引用。
-
虚引用也称为幽灵引用或者幻影引用,它是最弱的一种引用关系。对象是否有虚引用完全不会对其生存空间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时受到一个系统通知。在JDK1.2之后,提供了PhantomReference类来实现虚引用。
4. 生存还是死亡¶
finalize 方法在GC(垃圾回收器)决定回收一个不被其他对象引用的对象时调用
即使在可达性分析算法中不可达的对象,也并非是“非死不可”的,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:如果对象在进行可达性分析后法相没有与GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法,或finalize()方法已经被虚拟机调用过,虚拟机将这两种情况都视为"没有必要执行"
如果这个对象被判定为有必要执行finalize()方法,那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样做的原因是,如果一个对象在finalize()方法中执行缓慢,或者发生了死循环(更极端的情况),将很可能会导致F-Queue队列中其他对象永久处于等待,甚至导致整个内存回收系统崩溃。
finalize()方法时对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量,那在第二次标记时它被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。

测试代码:
/*
代码演示两点:
1. 对象可以在被GC时自我解救
2. 这种自救的机会只有一次,因为一个对象的finalize方法最多只会被系统自动调用一次
*/
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 :(
5. 回收方法区¶
-
Java虚拟机规范中说过,可以不要求虚拟机在方法区实现垃圾收集,并且在方法区中进行垃圾收集的“性价比”一般比较低。
-
永久代的垃圾回收主要回收两部分内容:废弃常量和无用的类
- 回收废弃常量和回收Java堆中的对象非常类似
-
回收“无用的类”条件比较苛刻,判断一个类是“无用的类”的条件:
- 该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例
- 加载该类的 ClassLoader 已经被回收
- 该类对应的 java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法