本篇介绍垃圾收集器和内存分配策略,内容大多数是从《深入理解Java虚拟机》中总结敲出来的,只为加深印象。
上一篇文章中提到过,程序计数器、虚拟机栈和本地方法栈都是线程私有内存,随线程而生,随线程而灭。栈中的栈帧随着方法的进入和退出而有条不紊的执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的,因此这几个区域的内存分配和回收都具有确定性,在这几个区域不需要过多考虑回收的问题,因为方法结束或线程结束时,内存自然就跟随着回收了。而java堆和方法区不一样,这部分内存的分配和回收都是动态的,垃圾回收器关注的就是这部分。
对象已死吗
垃圾收集器在对堆进行回收前,需要确定哪些对象还“存活”,哪些对象已经“死去”(不可能被任何途径使用的对象)。判断方法有引用计数算法和可达性分析算法。
引用计数算法
给对象添加一个引用计数器,每当有一个对象引用它时,计数器的值就加1;当引用失效时,计数器的值减1;计数器的值为0时就是不可能再被使用的。
引用技术算法实现简单,判定效率高,但主流的Java虚拟机中没有使用引用计数算法来管理内存,主要因为很难解决对象之间相互循环引用的问题。例如:
public class ReferenceCountingGC {
public Object instance = null;
public static void testGC(){
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
//假设在这里发生GC
System.gc();
}
}
objA和objB相互引用,实际上这两个对象不可能再被访问,但引用计数都不为0,因此GC收集器不会回收它们。
可达性分析算法
主流程序语言的主流实现中都是通过可达性分析(Reachability Analysis)来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。如下图,object5、object6和object7到GC Roots是不可达的,因此会被判定是可回收对象。
在Java语言中,可作为GC Roots的对象包括以下几种:
- 虚拟机栈(栈帧中的本地变量表)中引用的对象;
- 方法区中类静态属性引用的对象;
- 方法区中常量引用的对象;
- 本地方法栈中JNI(即一般说的Native方法)引用的对象。
再谈引用
在JDK1.2以前,一个对象只有引用或者被引用两种状态,对于如何描述一些“食之无味弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象:当内存空间还足够时,能保留在内存中;如果内存空间在进行垃圾收集后还是非常紧张,则可以抛弃这些对象。很多系统的缓存功能都有这样的应用场景。
在JDK1.2以后,引用的概念得到了扩充,分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)四种,这四种引用强度依次逐渐减弱。
- 强引用:就是指在代码之中普遍存在的,类似“Object obj = new Object()”这类的引用,只要强引用还存在,垃圾收集器永远不会回收被引用的对象;
- 软引用:用来描述一些还有用但非必需的对象。对于软引用关联着的对象,在系统将要发生内存溢出异常之前,将会将这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存,才会抛出内存溢出异常。在JDK1.2之后,提供了SoftReference类来实现软引用;
- 弱引用:也是用来描述非必需对象的。但它的强度比弱引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。在JDK1.2之后,提供了WeakReference类来实现弱引用;
- 虚引用:也称为幽灵引用或幻影引用,是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后,提供了PhantomReference类来关联虚引用。
标记过程
在可达性分析算法中不可达的对象也并非是“非死不可”的,要真正宣告一个对象死亡,至少要经历两次标记过程。
- 对象在经过可达性分析后发现没有与GC Roots相连的引用链,那它将被第一次标记并进行筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者finalize()方法已经被调用过,虚拟机将这两种情况都视为“没有必要执行”。如果这个对象被判定为有必要执行finalize()方法,则进入第二次标记过程;
- 进入第二次标记过程的对象首先会被放入一个叫做F-Queue的队列中,并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里的所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,因为如果F-Queue中的一个对象在finalize()方法中执行缓慢或者进入死循环,很可能导致队列中其他对象永久出于等待,甚至导致整个内存回收系统崩溃。finalize()方法时对象逃脱死亡的最后一次机会,稍后GC将对F-Queue队列中的对象进行第二次标记,如果对象重新与引用链中的任何一个对象建立关联,在第二次标记时它将被移出“即将回收”的集合,否则就会被真的回收。
回收方法区
永久代的垃圾收集主要回收两部分内容:废弃常量和无用的类。以常量池中字面量的回收为例,假如一个Integer值为1已经在常量池中,但当前系统中没有任何一个Integer对象的值为1,即没有任何Integer对象引用1这个常量,也没用其他地方引用了这个字面量,这时发生内存回收,而且必要的话,这个常量1就会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
判断一个类是否是“无用的类”需要同时满足以下三个条件:
- 该类的所有实例都已经被回收,也就是Java堆中不存在该类的任何实例;
- 加载该类的ClassLoader已经被回收;
- 该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
垃圾收集算法
标记-清除算法
标记-清除算法分为“标记”和“清除”两个阶段,首先标记出所有需要回收的对象,在标记完成之后统一回收所有被标记的对象,标记过程也就是前面介绍过的标记过程。
标记-清除算法回收前:
标记-清除算法回收后:
标记-清除算是是最基本的算法,后续的收集算法都是基于这种思路并对其不足进行改进。主要不足有两个:
- 效率问题,标记和清除两个过程的效率都不高;
- 空间问题:标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
复制算法
复制算法将可用内存按容量分为大小相等的两块,每次只使用其中一块。当这块内存用完了,就将还存活的对象复制到另一块上面,然后把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况。只要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效。只是这种算法的代价是将内存缩小为原来的一半。
复制算法回收前:
复制算法回收后:
标记-整理算法
复制算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。更关键的是,如果不想浪费50%的空间,就需要有额外的空间进行分配担保,以应对被使用空间中所有对象都100%存活的极端情况。
标记-整理算法的标记过程与标记-清除算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
标记-整理算法回收前:
标记-整理算法回收后:
分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”算法,这种算法根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集都会有大批对象死去,只有少量存活,因此新生代使用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
新生代与老年代占用堆空间比例是1:2,新生代又分为一个大的Eden区和两个相同大小的Survivor区,在HotSpot虚拟机中的比例为8:1:1。每次新生代中只会有Eden区和一个Survivor区提供服务,也就是说新生代每次可使用空间为90%,将Eden区和一个Survivor区经过一次Minor GC(新生代GC)后仍然存活的对象使用复制算法放入另一个Survivor区,然后清理掉Eden区和当前的Survivor区。
新生代回收前:
新生代回收后: