【JVM】垃圾收集器GC详解

前言

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里 面的人却想出来。

在Java管理的内存中，Java的程序计数器、虚拟机栈、本地方法栈由于是随线程而生，也随着线程结束而回收的，因此其内存区域管理有着相当的确定性。

Java堆和方法区这两个区域则有着很显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也可能不一样，只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器所关注的正是这部分内存该如何管理

初探垃圾回收算法

引用计数法

最经典的回收算法，在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的，此时该对象就可以被回收。

引用计数法原理和实现都十分简单，效率也不错，但是目前主流的JVM都不使用该法。这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。如果A引用B，B引用A，那么这两个对象将会永远不会被回收，哪怕已经没有别的地方需要使用它们了。

可达性分析

当前主流的JVM使用的都是可达性分析的方法判断一个对象是否需要被回收。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”，如果某个对象到GC Roots间没有任何引用链相连， 或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

如上图，object5\6\7虽然仍然互相有引用，但是不可达，依旧会被回收。

在Java中，如下对象可以作为GC root对象：

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等
• 在方法区中类静态属性引用的对象和常量引用的对象
• 所有被同步锁（synchronized关键字）持有的对象。
• 在本地方法栈中Native方法引用的对象
• Java虚拟机内部的引用，如基本数据类型对应的Class对象

除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没 有与GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。如果这个对象被判定为确有必要执行finalize()方法，那么该对象将会被放置在一个名为F-Queue的 队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize() 方法

引用

我们发现，涉及到内存回收，我们都离不开一个概念——引用。在JDK1.2之前，Java的引用类型比较的丁真（也就是单纯），只分为被引用和未被引用两种状态，但是这无法满足较为复杂的对象引用和回收要求。因此1.2之后，将引用分为强引用（Strongly Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱

• 强引用是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象
• 软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内 存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，使用SoftReference类来实现软引用
• 弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉。使用WeakReference类来实现弱引用
• 虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。使用PhantomReference类来实现虚引用

回收方法区

上面我们简单谈了下Java堆是怎么回收的，接下来我们聊聊有关方法区的回收，在《JVM虚拟机规范》中提到过可以不要求虚拟机在方法区中实现垃圾收集，而方法区垃圾收集 的“性价比”通常也是比较低的，它并不如堆一样可以一次回收很多空间。

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

要判定一个类型是否属于“不再被使用的类”的条件就 比较苛刻了。需要同时满足下面三个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收，这个条件通常是很难达成。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

垃圾收集算法

分代收集理论

当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”的理论进行设计。这建立在两个假说之上：

• 弱分代假说：绝大多数对象都是朝生夕灭的。也就是大多数对象都是创建完后立即使用，然后就不再需要了。
• 强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡。也就是在某时刻之前被频繁使用的对象，在之后大概率还是会被频繁使用的。

这两个假说奠定了多个主要GC的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域中存储。

JVM一般至少会把Java堆划分为新生代和老年代两个区域。在新生代中，每次垃圾收集时都发现有大批对象死去，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。但是这仍然不够，假如要现在进行一次只局限于新生代区域内的收集（Minor GC），但新生代中的对象是完全有可能被老年代所引用的，为了找出该区域中的存活对象，不得不在固定的GC Roots之外，再额外遍历整 个老年代中所有对象来确保可达性分析结果的正确性，这会导致很大的性能负担。

为了解决上述的问题，我们提出第三条假说：

• 跨代引用假说：跨代引用相对于同代引用来说仅占极少数。

这条假说的提出是因为存在互相引用关系的两个对象，应该倾向于同时生存或者同时消亡的。举个例子，如果某个新生代对象存在跨代引用老年代，由于老年代对象难以消亡，该引用会使得新生代对象在收集时同样得以存活，进而在年龄增长之后晋升到老年代中，这时跨代引用也随即被消除了

因此，我们就不应再为了少量的跨代引用去扫描整个老年代，只需在新生代上建立一个全局的数据结构（该结构被称为记忆集），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。

GC的收集行为可以分为以下数类：

• 部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为
  • 新生代收集（Minor GC）：指目标只是新生代的垃圾收集。
  • 老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集
• 整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

标记-清除算法

这是最早基础的垃圾收集算法。算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。

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

标记-复制算法

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，并且将它们顺序放置，然后再把已使用过的内存空间一次清掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，其性能就比标记-清除算法要优秀不少。但是缺点也很明显：这种复制回收算法的代价是将可用内存缩小为了原来的一半，空间浪费未免太多了一点

现在的JVM大多数优先使用此法回收新生代，IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集，如此高比例的回收十分适合标记-复制算法。

Andrew Appel针对具备“朝生夕灭”特点的对象，提出了“Appel式回收”。Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍 然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和两个Survivor的大小比例是8：1：1。由于在新生代，98%的对象都是要被回收的，因此仅占10%的Survivor区也足以容纳存活的对象。

标记-整理算法

标记-复制算法在对象存活率较高时就要进行较多的复制操作，对于多数对象存活的情况并不适用，所以在老年代一般不能直接选用这种算法。

针对老年代对象的存亡特征，提出了另外一种标记-整理算法，刚开始对存活的对象进行标记，但时候后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作; 但如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话，弥散于堆中的存活对象导致的 空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。

基于以上两点，有些虚拟机会更倾向于移动，而一些虚拟机则倾向于保留碎片直到无法容忍的时候进行一次大清除。而最新的ZGC收集器使用读屏障技术实现了整理过程与用户线程的并发执行。