​虚拟机夯实基础系列-垃圾回收机制深入浅出

1.1 概述

垃圾收集（Garbage Collection，简称 GC）需要完成的三件事情：哪些内存需要回收？什么时候回收？如何回收？

1.2 对象已死？

在堆里面存放着 Java 世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件 事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（“死去”即不可能再 被任何途径使用的对象）了。

1.2.1 引用计数算法

很多教科书判断对象是否存活的算法是这样的：在对象中添加一个引用计数器，每当有一个 地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的 对象就是不可能再被使用的。
客观地说，引用计数算法（Reference Counting）虽然占用了一些额外的内存空间来进行计 数，但它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。也有一些 比较著名的应用。但是这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处 理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。 例如对象 objA 和 objB 都有字段 instance，赋值令 objA.instance=objB 及 objB.instance =objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但 是它们因为互相引用着对方，导致它们的引用计数都不为零，引用计数算法也就无法回收它 们。

1.2.2 可达性分析算法

可达性分析（Reachability Analysis）的基本思路就是通过一系列称为“GC Roots”的根 对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称 为“引用链”（Reference Chain），如果某个对象到 GC Roots 间没有任何引用链相连，或者用图论的话来说就是从 GC Roots 到这个对象不可达时，则证明此对象是不可能再被使用的。

如图所示，对象 object 5、object 6、object 7 虽然互有关联，但是它们到 GC Roots 是不 可达的，因此它们将会被判定为可回收的对象。

在 Java 技术体系里面，固定可作为 GC Roots 的对象包括以下几种： ·

·在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。 ·

• 在方法区中类静态属性引用的对象，譬如 Java 类的引用类型静态变量。

• 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。

• 在本地方法栈中 JNI（即通常所说的 Native 方法）引用的对象。

• Java 虚拟机内部的引用，如基本数据类型对应的 Class 对象，一些常驻的异常对象（比如 NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。

• 所有被同步锁（synchronized 关键字）持有的对象。

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

1.2.3 再谈引用

在JDK 1.2版之后，Java对引用的概念进行了扩充，将引用分为强引用（Strongly Reference）、 软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）4种，这 4 种引用强度依次逐渐减弱。

• 强引用是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似 “Object obj=new Object()”这种引用关系。无论任何情况下，只要强引用关系还存在， 垃圾收集器就永远不会回收掉被引用的对象。

• 软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还 没有足够的内存，才会抛出内存溢出异常。在 JDK 1.2 版之后提供了 SoftReference 类来 实现软引用。

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

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

1.2.4 生存还是死亡

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还 处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行 可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记，随后进行一 次筛选，筛选的条件是此对象是否有必要执行 finalize()方法。假如对象没有覆盖 finali -ze()方法，或者 finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没 有必要执行”。 如果这个对象被判定为确有必要执行 finalize()方法，那么该对象将会被 放置在一个名为 F-Queue 的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级 的 Finalizer 线程去执行它们的 finalize()方法。finalize()方法是对象逃脱死亡命运的 最后一次机会，稍后收集器将对 F-Queue 中的对象进行第二次小规模的标记，如果对象要在 finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如 把自己（this 关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被 移出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的要被回收了。 任何一个对象的 finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收， 它的 finalize()方法不会被再次执行。

1.2.5 回收方法区

方法区的垃圾收集主要回收两部分内容：废弃的常量和不再使用的类型。

回收废弃常量：假如一个字符串“java”曾经进入常量池中，但是当前系统又没有任何一个 字符串对象的值是“java”，换句话说，已经没有任何字符串对象引用常量池中的“java” 常量，且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收，而且垃圾收 集器判断确有必要的话，这个“java”常量就将会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用也与此类似。

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类” 的条件就比较苛刻了。需要同时满足下面三个条件：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例。

• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景， 如 OSGi、JSP 的重加载等，否则通常是很难达成的。

• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问 该类的方法。

Java 虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”， 而并不是和对象一样，没有引用了就必然会回收。

1.3 垃圾收集算法

本节介绍的所有算法均属于追踪式垃圾收集的范畴

1.3.1 分代收集理论分代收集（Generational Collection）

名为理论，实质是一套符合大多数程序运行实际情 况的经验法则，它建立在两个分代假说之上：

弱分代假说（Weak Generational Hypothesis：绝大多数对象都是朝生夕灭的。

强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消亡。

收集器将 Java 堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象，就能以较低代价回收到大量的空间；如果剩下的都是难以 消亡的对象，那把它们集中放在一块，虚拟机便可以使用较低的频率来回收这个区域。把分代收集理论具体放到现在的商用 Java 虚拟机里，设计者一般至少会把 Java 堆划分为新生代（Young Generation）和老年代（Old Generation）两个区域。顾名思义，在新生代中，每次垃圾收集时都发现有大批对象死去，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。

分代收集并非只是简单划分一下内存区域那么容易，它至少存在一个明显的困难：对象不是 孤立的，对象之间会存在跨代引用。跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。 如果某个新生代对象存在跨代 引用，由于老年代对象难以消亡，该引用会使得新生代对象在收集时同样得以存活，进而在 年龄增长之后晋升到老年代中，这时跨代引用也随即被消除了。依据这个，我们就不应再为 了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在 哪些跨代引用，只需在新生代上建立一个全局的数据结构（该结构被称为“记忆集”， Remembered Set），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存 在跨代引用。此后当发生 Minor GC 时，只有包含了跨代引用的小块内存里的对象才会被加 入到 GCRoots 进行扫描。

• 部分收集（Partial GC）：指目标不是完整收集整个 Java 堆的垃圾收集，其中又分为：
  ■ 新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
  ■ 老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有 CMS 收集器 会有单独收集老年代的行为。另外请注意“Major GC”这个说法现在有点混淆， 在不同资料上常有不同所指，读者需按上下文区分到底是指老 年代的收集还是整堆收集。
  ■ 混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目 前只有 G1 收集器会有这种行为。
• 整堆收集（Full GC）：收集整个 Java 堆和方法区的垃圾收集。

1.3.2 标记-清除算法 “标记-清除”（Mark-Sweep）算法

分为“标记”和“清除”两个阶段：首先标记出所有需 要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活对象，统一回收所有未被标记的对象。它的主要缺点有两个：第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清 除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；第二个是内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致 当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发 另一次垃圾收集动作。标记-清除算法的执行过程如图所示。

1.3.3 标记-复制算法

Appel 式回收的具体做法是把新生代分为一块较大的 Eden 空间和两块较小的 Survivor 空间， 每次分配内存只使用 Eden 和其中一块 Survivor。发生垃圾搜集时，将 Eden 和 Survivor 中 仍然存活的对象一次性复制到另外一块 Survivor 空间上，然后直接清理掉 Eden 和已用过的 那块 Survivor 空间。HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8∶1，也即每次 新生代中可用内存空间为整个新生代容量的 90%（Eden 的 80%加上一个 Survivor 的 10%）， 只有一个 Survivor 空间，即 10%的新生代是会被“浪费”的。Appel 式回收还有一个充当罕 见情况的“逃生门”的安全设计，当 Survivor 空间不足以容纳一次 Minor GC 之后存活的对 象时，就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。 如果另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来的存活对象，这些对 象便将通过分配担保机制直接进入老年代，这对虚拟机来说就是安全的。

1.3.4 标记-整理算法

“标记-整理”（Mark-Compact）算法，其中的标记过程仍然与“标记-清除”算法一样，但 后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动， 然后直接清理掉边界以外的内存，“标记-整理”算法的示意图如图所示。

标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是 移动式的。HotSpot 虚拟机里面关注吞吐量的 Parallel Scavenge 收集器是基于标记-整理 算法的，而关注延迟的 CMS 收集器则是基于标记-清除算法的。还有一种“和稀泥式”解决 方案可以不在内存分配和访问上增加太大额外负担，做法是让虚拟机平时多数时间都采用标 记-清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分 配时，再采用标记-整理算法收集一次，以获得规整的内存空间。前面提到的基于标记-清除 算法的 CMS 收集器面临空间碎片过多时采用的就是这种处理办法。

​