深入JVM之垃圾收集（GC）算法

深入JVM之垃圾收集（GC）算法

前言

前面介绍了Java运行数据区域，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；每一个帧栈中分配多少内存基本上是在类结构确定下来就已知的。这几个区域不需要过多考虑回收的问题，因为方法结束或者线程结束时；内存自然就跟着回收了。而Java堆和方法区则不一样，只有在程序运行期间才能知道会创建哪些对象，这部分的分配和回收都是动态的，垃圾收集所关注的也仅指这部分内存。

判断对象是否已死

垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象是否“存活”，判断对象存活有两种方法，引用计数法和可达性分析算法。

引用计数法

给对象添加一个引用计数器，没当有一个地方引用它时，计数器指就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

引用计数法实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。但是主流的Java虚拟机里面没有选用引用计数法来管理内存。其中最主要的原因是它很难解决对象之间的相互循环引用问题。

public class Test {
    
    public Object obj = null;
    
    public static void main(String[] args) {
       Test a = new Test();
	   Test b = new Test();
       a.obj = b;
	   b.obj = a;
	   a = null;
	   b = null;
	   System.gc();
    }
}

上面的例子中a,b两个对象都不能再被访问，但是因为obj对象存在相互引用，导致他们的引用计数都不为0，于是引用计数法就无法通知GC收集器回收它们。

可达性分析算法

在主流的商用程序语言（Java、c#）的主流实现中，都是通过可达性分析来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始往下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明对象是不可用的。

在Java语言中，可作为GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法中JNI（即一般说的Native方法）引用的对象。

引用类型

无论是通过引用计数法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判断对象是否存活都与引用有关。在JDK1.2之后，Java堆引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用4中，这四种引用强度依次逐渐减弱。

• 强引用：强引用就是指程序代码之中普遍存在的，类似“Object obj = new Object() ”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

  Object obj = new Object();
  

• 软引用：软引用用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，在JDK1.2之后，提供了SoftReference类来实现软引用。

  Object obj = new Object();
  SoftReference<Object> sf = new SoftReference<Object>(obj);
  obj = null;  // 使对象只被软引用关联
  

• 弱引用：弱引用是用来描述非必需对象的，但是他的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。

  Object obj = new Object();
  WeakReference<Object> wf = new WeakReference<Object>(obj);
  obj = null;
  

• 虚引用也被称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能够在这个对象被收集器回收时收到一个系统通知，在JDK1.2之后，提供了PhantomRenference类来实现虚引用。

  Object obj = new Object();
  PhantomReference<Object> pf = new PhantomReference<Object>(obj, null);
  obj = null;
  

垃圾收集算法

标记-清除算法

最基础的收集算法是“标记-清除（Mark-Sweep）”算法，如同他的名字一样，算法分成“标记”和“清除”两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它主要有两个不足：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能导致以后再程序运行过程中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集动作。

复制算法

为了解决效率问题，一种称为“复制（Copying）”的收集算法出现了，他讲可用内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间依次清理掉。这样使得每次都是针对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况。只是这种算法的代价是将内存缩小为原来的一半。

现在的商业虚拟机都采用这种收集算法来回收新生代，但是并不是划分为大小相等的两块，而是一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象全部复制到另一块 Survivor 上，最后清理 Eden 和使用过的那一块 Survivor。

HotSpot 虚拟机默认 Eden 和 Survivor 大小比例默认为 8:1，保证了内存的利用率达到 90%。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 就不够用了，此时需要依赖于老年代进行空间分配担保，也就是借用老年代的空间存储放不下的对象

标记-整理算法

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费空间，就需要额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接用这种算法。

标记-整理（Mark-Compact）算法和标记清除算法一样分为两个步骤。标记过程相同，但后续步骤不是直接堆可回收的兑现进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集算法”，这种算法并没有新的思想，只是根据对象存活周期的不同将内存划分为几块。一般把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集都发现大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而年老代中因为对象存活率高、没有额外空间对他进行担保，就必须使用**“整理–清理”**算法来进行回收。

参考书籍：《深入理解Java虚拟机》

参考博客：Java 虚拟机