垃圾回收机制主要考虑完成三件事：
1、哪些内存需要回收？
2、什么时候回收？
3、如何回收？

堆中几乎存放着所有的对象实例，垃圾收集器在对堆进行回收前，要判断哪些对象还“存活”？ 哪些对象已经“死去” 需要进行回收？

引用计数法

在对象中添加一个引用计数器，每当有一个地方引用时，计数值加1，当引用失效时，计数器值减1。任何时刻计数器为零的对象就是不可能再被使用。
引用计数法虽然占用了额外的内存空间用来计数，但原理简单，判定效率也非常高，但有很多的例外情况需要考虑，必须配合大量额外处理才能保证正确工作，譬如单纯的引用计数很难解决对象间的相互循环引用的问题。

  1. /*** testGC()方法执行后，objA和objB会不会被GC呢？ **/ 
  2. public class ReferenceCountingGC { 
  3.     public Object instance = null; 
  4.     private static final int _1MB = 1024 * 1024; 
  5.     /*** 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否有回收过 */ 
  6.     private byte[] bigSize = new byte[2 * _1MB]; 
  7.     public static void testGC() { 
  8.         ReferenceCountingGC objA = new ReferenceCountingGC(); //A引用+1
  9.         ReferenceCountingGC objB = new ReferenceCountingGC(); //B引用+1
  10.         objA.instance = objB; //B引用+1
  11.         objB.instance = objA; //A引用+1
  12.         objA = null; //A引用-1
  13.         objB = null; //B引用-1
  14.         System.gc();  //无法被回收
  15.     } 
  16. }

如上代码，对象objA和objB都有字段instance，复制命令objA.instance = objB和objB.instance = objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但他们因为互相引用。导致他们的引用计数都不为零，引用计数算法也就无法回收他们。

可达性分析算法

可达性分析算法是通过一系列称为“GC Roots” 的根对象作为起始节点集，从这个节点开始，根据引用关系向下搜索，搜索过程走过的路径称为“引用链”，如果这个对象到GC Roots之间没有任何引用链相连，或者用图论的话来说就是从GCRoots到这个对象不可达时，则证明此对象不可能再被使用。
如图示，object5、object6、object7 虽然互有关联，但是他们到GC Roots是不可达的，因此被判定为可回收对象。
image.png

可作为GC Roots对象包括以下几种：

  • 在栈中引用的对象。包括参数、局部变量、临时变量等。
  • 在方法区中类静态属性引用的对象。（static 修饰的引用类型静态变量）
  • 方法区中常量引用的对象，譬如字符串常量池里（String Table）的引用
  • 在本地方法栈中JNI（native方法）引用的对象
  • 虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如 NullPointExceptionn、OutOfMemoryError）等，还有系统加载器。
  • 所有被同步锁持有的对象。

  • 反映虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

    引用关系

    在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为：

    • 强引用
    • 软引用
    • 弱引用
    • 虚引用

      这四种引用关系依次减弱

  • 强引用是最传统的引用定义，指引用赋值（Object obj = new Object()）。无论任何情况下，只要强引用关系还存在，永远不会被回收。

  • 软引用是用来描述一些还有用，但非必须的对象。只有被软引用关联的对象，在将要发生内存溢出异常前，会把这些对象列进回收范围中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。jdk 1.2 之后提供了SoftReference类 来实现软引用。
  • 弱引用也是用来描述非必须对象，但是它的强度比软引用更弱一些，被软引用关联的对象只能生存到下一次垃圾回收发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。JDK1.2之后提供了WeakReference类来实现弱引用。
  • 虚引用也称为“幽灵引用”或者“幻影引用”，是最弱的引用关系，一个对象是否有虚引用存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被垃圾回收时收到一个系统通知。JDK1.2之后提供了PhantReference类来实现虚引用。

垃圾收集算法

标记-清除算法

垃圾回收机制 - 图2

  1.     算法分为`“标记”`和`“清除”`两个阶段：首先标记出所有需要被回收的对象，标记完成后，统一回收掉所有被标记的对象。也可以反过来，标记存活的对象，回收所有未被标记的对象。
  3.     标记-清除算法是最基础的收集算法，后续的收集算法大多以标记-清除算法为基础，对其缺点进行改进而得到。
  5.     标记-清除算法主要缺点有两个：1、执行效率不稳定，如果堆中有大量对象，其中大部分需要回收，必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率随对象数量增长而降低。2、内存空间的碎片化问题，标记、清除后产生大量不连续的内存碎片，空间碎片太多可能会导致后续分配大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集操作。

标记-复制算法

垃圾回收机制 - 图3

标记-复制算法简称复制算法，为了解决标记-清除算法面对大量可回收对象时效率低的问题。标记-复制算法将可用内存按容量划分为大小相等的两块每次只是用其中一块。当这一块用完了，就将还存活的对象复制到另一块上，然后将已使用过的内存空间一次性清理。

如果内存中多数对象都是存活的，标记复制算法将产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑空间碎片的复杂情况，只需要移动对顶指针，按顺序分配即可。

这样实现简单，运行高效，但是代价是将可用内存缩小为原来的一般，空间浪费。

虚拟机大多优先采用这种收集算法回收新生代，

标记-清理算法

垃圾回收机制 - 图4

标记-复制算法在对象存活率较高时就要进行较多的赋值操作，效率降低。针对老年代对象的存亡特征，标记-整理算法应运而生，其中标记过程与标记-清除算法一样，但后续步骤直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后清理边界以外的内存。

标记清除和标记整理算法的本质差异在于前者是非移动式的回收算法，后者是移动式的。如果移动存活对象，尤其对于老年代每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将是一种极为负重的操作，而且对象移动操作必须全程暂停用户应用程序才能进行。相反，如果不移动对象，弥散于堆中的存活对象导致空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决；内存访问是用户程序最频繁的操作，在这个环节增加额外的负担，势必会直接影响应用程序的吞吐量。

垃圾回收机制 - 图5

分代收集理论

当前虚拟机多数遵循分代收集的理论进行设计，建立在两个假说之上：

  • 弱分代假说：绝大数对象都是朝生夕灭
  • 强分代假说：熬过越多次垃圾收集过程的对象越难以消亡。

收集器应将Java堆划分出不同区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同区域进行存储。如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，将它们集中放在一起，每次回收只关注如何保留少量存活对象而不是去标记那些大量将要被回收的对象，就能以较低价会受到大量的空间；如果剩下的都是难以消亡的对象，将它们集中放在一起，使用较低的频率回收这个区域，同时兼顾了垃圾回收的时间开销和内存的空间有效利用。

在堆中划分出不同区域，垃圾收集器每次只回收其中某一个或某些部分区域。因而有了MinorGC MajorGC FullGC回收类型的划分。

  • 部分收集（PartialGC）：目标不是完整收集整个堆的垃圾收集
    • 新生代收集（MinorGC/YoungGC）:目标只是新生代的垃圾收集
    • 老年代收集（MajorGC/OldGC）：目标只是老年代的垃圾收集。目前只有CMS收集器有单独收集老年代的行为。
    • 混合收集（MixedGC）：目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器有这种行为
  • 整堆收集（FullGC）：收集整个Java堆和方法区的垃圾收集