一张图看懂 JVM 之垃圾回收机制

• 导读
• 什么是垃圾回收？
• 哪些内存需要回收？
• 如何判断对象已成垃圾？
• • 引用计数法
  • 可达性分析算法
  • 四种引用方式
  • • 强引用
    • 软引用
    • 弱引用
    • 虚引用
    • 引用小结
• 垃圾收集算法
• • 标记-清除算法
  • 标记-复制算法
  • 标记-整理算法
  • 分代收集算法
• 分代收集理论
• • 为什么要分代？
  • 内存分代划分
  • • Eden 区
    • Survivor 区
    • • 为啥需要 Survivor 区？
    • 老年代（Old Gen）
    • 堆内存常见的分配策略
    • • 对象优先在 Eden 区分配
      • 大对象直接进入老年代
      • 长期存活的对象将进入老年代
• 总结

有这样一个梗，说在食堂里吃饭，吃完把餐盘端走清理的，是 C++ 程序员，吃完直接就走的，是 Java 程序员。

确实，在 Java 的世界里，似乎我们不用对垃圾回收那么的专注，很多初学者不懂 GC，也依然能写出一个能用甚至还不错的程序或系统。但其实这并不代表 Java 的 GC 就不重要。相反，它是那么的重要和复杂，以至于出了问题，那些初学者除了打开 GC 日志，看着一堆 0101 的天文，啥也做不了。

今天我们就从头到尾完整地聊一聊 Java 的垃圾回收。

我们通过一张图的方式，从总体上对 JVM 的结构特别是内存结构有一个比较清晰的认识。

虽然在 JDK1.8+ 的版本中，JVM 内存管理结构有了一定的优化调整：主要是方法区（持久代）取消变成了直接使用元数据区的方式，但是整体上 JVM 的结构并没有大改，特别是我们最为关心的堆内存管理方式并没有在 JDK1.8+ 的版本中有什么变化。

在上面的图中，我们也大致对整个垃圾回收系统进行了标注，这里主要涉及回收策略、回收算法、垃圾回收器这几个部分。

形象一点表述，就是 JVM 需要知道哪些内存可以被回收，要有一套识别机制，在知道哪些内存可以回收以后具体采用什么样的回收方式，这就需要涉及一些回收算法，而具体的垃圾回收器就是根据不同内存区域的使用特点，采用相应地回收策略和算法的具体实现了。

下面我们就从这几个方面给大家介绍，JVM的垃圾回收相关的知识点。

垃圾回收（Garbage Collection，GC），顾名思义就是释放垃圾占用的空间，防止内存泄露。有效的使用可以使用的内存，对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收。

我们知道，根据 《Java虚拟机规范》，Java 虚拟机运行时数据区分为程序计数器、虚拟机栈、本地方法栈、堆、方法区。

而程序计数器、虚拟机栈、本地方法栈这 3 个区域是线程私有的，会随线程消亡而自动回收，所以不需要过多考虑如何回收的问题。

而 Java 堆区和方法区则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。

既然是垃圾收集，我们得先判断哪些对象是垃圾，然后再看看何时清理，如何清理。

常见的垃圾回收策略分为两种：

• 一种是直接回收，即引用计数；
• 另一种是间接回收，即追踪式回收（可达性分析）。

• 引用计数法是通过在对象头中分配一个空间来保存该对象被引用的次数（Reference Count）
• 每当有一个地方引用它，引用计数就加 1
• 当引用失效，它的引用计数就减 1
• 当该对象的引用计数减少为 0 的时候，就意味着这个对象再也无法被引用了，所以可以立即释放内存
  

优点：实现简单，效率高。

缺点：

1. 需要占据额外的存储空间，如果本身的内存单元较小，则计数器占用的空间就会变得明显。
2. 很难解决对象之间相互循环引用的问题。

所谓对象之间的相互引用问题，如下面代码所示：

public class ReferenceCountingGc {
    Object instance = null;

    public static void main(String[] args) {
        ReferenceCountingGc objA = new ReferenceCountingGc();
        ReferenceCountingGc objB = new ReferenceCountingGc();
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;
    }
}

• 定义 2 个对象
• 相互引用
• 置空各自的声明引用

除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。

但是它们因为互相引用对方，导致它们的引用计数器都不为 0，通过引用计数算法，也就永远无法通知 GC 收集器回收它们。

可达性分析算法（Reachability Analysis）的基本思路：

• 首先要确定一系列根对象（GC Roots）
• 并从根对象为起点根据对象之间的引用关系搜索出一条引用链（Reference Chain）
• 当一个对象到 GC Roots 没有任何引用链相连时，我们就称之为对象引用不可达，则证明这个对象是不可用的，就可以暂时判定这个对象为可回收对象。

有一个比喻十分恰当：可达性分析算法就好比是在清洗葡萄串，我们可以从一根枝提起一大串葡萄，他们就像一串引用链，而没有和引用链相连的对象就像是散落在池子里的葡萄，可以回收。

在图中虽然 Object 6 与 Object 7 之间互相有关联，但是它们到 GC Roots 是不可达的，所以将会被判定为可回收对象。

通过可达性算法，成功解决了引用计数所无法解决的问题「循环依赖」，只要你无法与 GC Roots 建立直接或间接的连接，系统就会判定你为可回收对象。那这样就引申出了另一个问题，哪些属于 GC Roots 。

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

• 虚拟机栈（栈帧中的本地变量表）中引用的对象（正在运行的方法使用到的变量、参数等）
• 方法区中类静态属性引用的对象（static 关键字声明的字段）
• 方法区中常量引用的对象，(也就是 final 关键字声明的字段)
• 本地方法栈中引用的对象（native 方法）
• 所有被同步锁（synchronized 关键字）持有的对象
• Java虚拟机内部的引用（系统内部的东西当然能作为根了）

无论是通过引用计数法判断对象引用数量，还是通过可达性分析法判断对象的引用链是否可达，判定对象的存活都与「引用」有关。

JDK1.2 之前，Java 中引用的定义很传统：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。

JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种，引用强度逐渐减弱。

正常情况下我们平时基本上我们只用到强引用类型，例如 Object obj = new Object();。

无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。且当内存空间不足抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠回收具有强引用的对象，来解决内存不足的问题。

软引用是种相对强引用弱化一些的引用，用来描述一些还有用，但非必须的对象。

软引用是通过 SoftReference 类实现的。

Object obj = new Object();
SoftReference softObj = new SoftReference(obj);
obj = null;

被软引用关联着的对象，在即将 OOM 之前，垃圾回收器会把这些软引用指向的对象加入回收范围，以获得更多的内存空间。如果这次回收还没有足够的内存，才会抛出内存溢出异常。

弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

弱引用是通过 WeakReference 类实现的。

Object obj = new Object();
WeakReference