我们知道电脑的内存是有限的,如果一段程序申请了一块内存空间并执行完计算之后,没有释放内存,会导致这块内存被占用,那么可用内存就变少了,如果一个系统很庞大,程序中迟早会把电脑内存耗尽的。为了提高内存的使用效率,内存在使用完必须释放,这样其他程序才可能重新申请这块内存。C语言中有malloc、free等于内存分配以及内存释放的函数。而Java中使用垃圾收集机制来整理内存空间。
Java的内存区域分为程序计数器、虚拟机栈、本地方法栈、Java堆和方法区,而且其中的程序计数器、虚拟机栈和本地方法栈都是线程独立的,也就是说这三块内存区域的生命周期与线程是同生共死的。栈中帧栈在类结构确定的时候就已经知道该分配多少内存了,所以当线程结束的时候,内存也跟着一起回收了,从这个角度看,这三块的内存区域的内存分配和垃圾收集就比较固定了。反观Java堆和方法区,比如我们定义一个接口,接口有着不同的实现类,而每个实现类的内存可能会不一样,每个实现类的方法的多个语句分支也可能需要的内存不一样。所以这两块区域的内存分配具有不确定性,那么在垃圾回收的时候自然也存在不确定性。
因此,在Java的垃圾收集机制中,关注的是Java堆和方法区这两块内存区域的垃圾回收。
给对象添加一个引用计数器,每当有一个地方引用它时,计数器值就加1,当引用失效时,计数器值就减1,任何时刻计数器为0的对象就是不可能再被使用的。
public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
// 这个成员属性的唯一意义就是占点内存,以便在能在GC日志中看清楚是否有回收过
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;
// 假设在这行发生GC,objA和objB是否能被回收?
System.gc();
}
}
际上这两个对象已经不可能再被访问,但是因为它们互相引用着对方,导致它们的引用计数值都不为0,引用计数算法无法通知GC收集器回收它们。
主流的商用程序语言(Java,C#)的主流实现中,都是通过可达性分析(Reachability Analysis)来判定对象是否存活的。
算法的基本思想就是通过一系列的称为“GC Roots”的对象作为起始点,从这些起始点开始向下搜索,所走过的路径称为引用链,如果一个对象到GC Roots没有任何引用链,那么这个对象是不可用的,就是说,程序中没有谁引用了这个对象,所以可以说从根节点到叶子结点是不可达的。
Java中,以下对象可作为GC Roots对象:
注意,及时在可达性分析算法中判定为可回收的对象(不可达),也并非是“非死不可”的。
原因在于要宣告一个对象的死亡,需要两次标记,如果一个对象没有与GC Roots结点相连,就会被第一次标记,并且进行一次筛选:此对象是否有必要执行finalize()方法。如果对象没有覆盖finalize()方法,或者该方法已经为JVM调用过了,则“没有必要执行”finalize()方法。如果对象覆盖了finalize方法,并且在finalize方法中与某个对象建立了引用关系例如把this关键字(自己)赋值给某个类变量或者对象的成员变量(GC Roots),那么第二次标记会失败,那么这个对象就会被移出“即将回收”的对象列表,移出之后这个对象就“活”了下来,如果在finalize方法中这个对相关仍然没有与一个对象建立引用关系,那么这个对象就真正死亡了。
下面的代码展示了自我拯救成功与失败的过程:
package com.jvm.GC;
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 mehtod executed!");
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC();
// 对象第一次成功拯救自己
SAVE_HOOK = null;
System.gc();
// 因为Finalizer方法优先级很低,暂停0.5秒,以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
// 下面这段代码与上面的完全相同,但是这次自救却失败了
// 因为finalize()已经执行过了,只调用一次
SAVE_HOOK = null;
System.gc();
// 因为Finalizer方法优先级很低,暂停0.5秒,以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
}
}
运行结果:
finalize mehtod executed!
yes, i am still alive :)
no, i am dead :(
注意:finalize()的运行代价高昂,不确定性大,无法保证各个对象的调用顺序,应该尽量避免使用。
前面说了,Java的内存回收主要实在方法区和Java堆中,Java堆中的新生代,因为新生代的存活时间比较短,所以对新生代进行垃圾回收回收的空间比较大,但是方法区中的永久代则由于可能存活时间较长,所以下一次的垃圾回收回收该对象的可能性没有新生代那么大。所以对永久代的回收效率会大打折扣。但是这部分对象仍然是需要回收。
永久代的垃圾回收包括两部分:废弃常量和无用的类
废弃常量的回收比较好理解,因为只要没有任何对象引用常量池中的某个对象,那么这个对象就会被回收。前面说的是非常量池中的对象,废弃常量回收的是运行时常量池中的对象,所以只需要一次标记就好。
无用的类回收需要满足以下三个条件才可以宣判一个类的“死刑”:
注意上面的“可以”而非“必然”。与对象的回收不同,是否需要对类进行回收,需要设置相关的参数才行。
在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能,以保证永久代不会溢出。
参考
1、周志明,深入理解Java虚拟机:JVM高级特性与最佳实践,机械工业出版社