通常JVM中的垃圾回收是针对于JAVA堆和方法区来说的。尤其是JAVA堆,因为很多对象的分配就是在此区域内,而方法区则存放了已经加载的类信息。那垃圾回收时如何判断堆中一个对象已经“死”了呢,即不会再需要它了呢。通常有两种方法
1.引用计数算法
通常来讲此算法是给对象添加一个引用计数器,每当有一个地方引用过它,计数器的值就加1;当引用失效时,计数器就减1,任何时刻计数器为0的对象就是不可能再被使用的。
能看出这种方法是比较简单粗暴,而且很高效的,但是却有一个缺陷,不能够解决对象间相互循环引用的问题:即objA引用了objB,objB也引用了objA,但是除去两者以外,无其他对象引用这两个对象。例如:
public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
private byte[] bigSize = new byte[2 * _1MB];
public static void testGC() {
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
System.gc();
}
public static void main(String[] args) {
testGC();
}
}
打印出日志如下,能看出两者还是被回收了,说明JVM未使用此算法来判断对象是否已死。(在JDK1.8下的结果)
2.可达性分析算法
此算法应用比较广泛,算法思想为:通过一系列的成为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径成为引用链,当一个对象到GC Roots没有任何引用链相连时,证明此对象是不可用的。
如图所示,Object5、Object6、Object7虽然相互关联,但是GC Roots到他们均为不可达,所以这三个对象会被判定为可回收的对象
通过以上表述能看出关键在于这些GC Roots,在Java中可作为Gc Roots的对象包括下面几种:
- 虚拟机栈(栈帧中的本地变量表)中引用的对象。
- 方法区中类静态属性引用的对象。
- 方法区中常量引用的对象。
- 本地方法栈中JNI(即一般说的Native方法)引用的对象。
3.真正的回收过程
通常在JVM中使用可达性分析算法,但是即使对象被标注为不可达,也不是“非死不可”的,要真正宣告一个对象死亡,至少要经历两次标记过程:
- 若对象在进行可达性分析后发现没有与GC Roots相连接的引用链,则会被第一次标记且进行一次筛选,筛选条件是此对象是否有必要执行finalize()方法。当对象①未覆盖finalize()方法或②finalize()方法已经被虚拟机调用过(任何一个对象的finalize()方法都会只被系统自动调用一次),虚拟机将这两种情况都视为“没有必要执行”。
- 若对象被判定有必要执行finalize()方法,则将此对象放在一个叫做F-Queue的队列之中,稍后会有一个自动建立的、低优先级的Finalizer线程去执行队列中对象的finalize()方法,此处执行只是意味着触发此方法,但不保证其执行完毕。finalize()方法是对象逃脱死亡的最后一次机会,稍后GC会对F-Queue中的对象进行第二次小规模的标记,若对象在finalize()方法中拯救了自己(与引用链上的任何一个对象建立了关联,比如把this赋值给了某个类变量或对象的成员变量),那么第二次标记时会将此对象移除出“即将回收”的集合;若此时对象还进行自我拯救,则会真的被回收。
总结来看第一次标记是将有必要执行finalize()方法的对象筛选出来,第二次标记是将在finalize()方法中未进行自我拯救的对象筛选出来。最终筛选出来的对象会被真正的回收。
看一下测试代码:
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public void isAlive() {
System.out.println("yes, I'm still alive");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize method executed");
FinalizeEscapeGC.SAVE_HOOK = this; //(2) 拯救了自己,重新与引用链上对象关联
}
public static void main(String[] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC();
SAVE_HOOK = null; //(1) 丢失了引用,变为不可达
System.gc();
Thread.sleep(500);
if (SAVE_HOOK != null)
SAVE_HOOK = null;
else
System.out.println("no, I'm dead");
//(3) 再次丢失引用,因finalize方法已执行过一次,所以不能再次拯救自己了,最终变为不可达
SAVE_HOOK = null;
System.gc();
Thread.sleep(1000);
if (SAVE_HOOK != null)
SAVE_HOOK.isAlive();
else
System.out.println("no, I'm dead");
}
}
运行结果如下。可以看出在代码(1)处虽然SAVE_HOOK丢失了引用,但是在其finalize()方法代码(2)处中成功拯救了自己,而代码(3)处再次丢失了引用,但不会触发finalize()方法了,因为此方法只会被系统调用一次,所以最终被回收了。
finalize method executed
yes, I'm still alive
no, I'm dead
但是是不建议重载finalize()方法的,它的运行代价高昂,不确定性大,无法保证各个对象的调用顺序。
4. 再谈引用
上面我们谈到,两种判断对象死活的方法都用到了引用,而JDK1.2后,Java对引用的概念进行了扩充,将引用分为强引用、软引用、弱引用、虚引用,他们的引用强度依次逐渐减弱。
- 强引用就是指程序代码中普遍存在的,类似
Object obj = new Object()
这类的引用,只要强引用还存在,垃圾收集器永远不会回收掉被引用的对象。 - 软引用也是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象,在系统将要发生内存溢出异常之前,将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存,才会抛出内存溢出异常。在JDK1.2后,提供了WeakReference类来实现弱引用。
- 弱引用也用来描述非必需对象,且它的强度比软引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。JDK1.2后,提供了WeakReference类来实现弱引用。
- 虚引用是最弱的一中引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。JDK1.2后,提供了PhantomReference类来实现虚引用。
5. 回收方法区
方法区(永久代)的垃圾收集效率是较低的,但是也存在,主要回收两部分内容:废弃常量和无用的类。
回收废弃常量和回收Java堆中的对象很类似。例如常量池中字面量的回收,加入一个字符串“abc”已经进入到了常量池中,但是当前系统没有任何一个String对象是叫做“abc”的,也就是没有任何String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果这时发生内存回收,而且有必要的话,这个“abc”常量就会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
但相对的,判断一个类是否是“无用的类”条件较为苛刻,须同时满足下面三个条件
- 该类的所有实例都已经被回收,也就是Java堆中不存在该类的任何实例。
- 加载该类的ClassLoader已经被回收。
- 该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
当然满足上述条件只是说“可以”被回收,而不是和对象一样,不适用了就必然被回收。在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备卸载的功能,以保证永久代不会溢出。