Java GC垃圾收集底层原理

 

Java GC垃圾回收几乎是面试必问的JVM问题之一，本篇文章带领大家了解Java GC的底层原理，图文并茂，突破学习及面试瓶颈。

JVM内存结构补充

图中展示了堆中三个区域：Eden、From Survivor、To Survivor。从图中可以也可以看到它们的大小比例，准确来说是：8:1:1。为什么要这样设计呢，本篇文章后续会给出解答，还是根据垃圾回收的具体情况来设计的。

还记得在设置JVM时，常用的类似-Xms和-Xmx等参数吗？对的它们就是用来说设置堆中各区域的大小的。

(图片来源于网络)

控制参数详解：

• -Xms设置堆的最小空间大小。
• -Xmx设置堆的最大空间大小。
• -Xmn堆中新生代初始及最大大小（NewSize和MaxNewSize为其细化）。
• -XX:NewSize设置新生代最小空间大小。
• -XX:MaxNewSize设置新生代最大空间大小。
• -XX:PermSize设置永久代最小空间大小。
• -XX:MaxPermSize设置永久代最大空间大小。
• -Xss设置每个线程的堆栈大小。

对照上面两个图，再来看这些参数是不是没有之前那么枯燥了，它们在图中都有了对应的位置。

有没有发现没有直接设置老年代空间大小的参数？我们通过简单的计算获得。

1. 老年代空间大小=堆空间大小-年轻代大空间大小

对上面参数立即了，但记忆有困难？那么，以下几个助记词可能更好的帮你记忆和理解参数的含义。

Xmx（memory maximum）, Xms（memory startup）, Xmn（memory nursery/new）, Xss（stack size）。

对于参数的格式可以这样理解：

• -: 标准VM选项，VM规范的选项。
• -X: 非标准VM选项，不保证所有VM支持。
• -XX: 高级选项，高级特性，但属于不稳定的选项。

GC概述

垃圾收集（Garbage Collection）通常被称为“GC”，由虚拟机“自动化”完成垃圾回收工作。

思考一个问题，既然GC会自动回收，开发人员为什么要学习GC和内存分配呢？为了能够配置上面的参数配置？参数配置又是为了什么？

“当需要排查各种内存溢出，内存泄露问题时，当垃圾成为系统达到更高并发量的瓶颈时，我们就需要对GC的自动回收实施必要的监控和调节。”

JVM中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生随线程而灭。栈帧随着方法的进入和退出做入栈和出栈操作，实现了自动的内存清理。它们的内存分配和回收都具有确定性。

因此，GC垃圾回收主要集中在堆和方法区，在程序运行期间，这部分内存的分配和使用都是动态的。

下面通过概念和具体的算法来了解GC垃圾回收的过程。

如何判断对象存活

判断对象常规有两种方法：引用计数算法和可达性分析算法（Reachability Analysis）。

引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时计数器加1，引用释放时计数减1，当计数器为0时可以回收。

引用计数算法实现简单，判断高效，在微软COM和Python语言等被广泛使用，但在主流的Java虚拟机中没有使用该方法，主要是因为无法解决对象相互循环引用的问题。

可达性分析算法：基本思想是通过一系列称为“GC Root”的对象（如系统类加载器、栈中的对象、处于激活状态的线程等）作为起点，基于对象引用关系，开始向下搜索，所走过的路径称为引用链，当一个对象到GC Root没有任何引用链相连，证明对象是不可用的。

上图中中绿色部分为存活对象，灰色部分为可回收对象。虽然灰色部分内部依旧有关联，但它们到GC Root是不可达的。

面试问题

面试官，说说Java GC都用了哪些算法？分别应用在什么地方？

答：复制算法、标记清除、标记整理……

你还在单纯的死记硬背么？继续往下看，你会豁然开朗，再也不用死记硬背了。

标记清除算法

标记清除（Mark-Sweep）算法，包含“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。

标记清除算法是最基础的收集算法，后续的收集算法都是基于该思路并对其缺点进行改进而得到的。

主要缺点：一个是效率问题，标记和清除过程的效率都不高；另外是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制算法

复制（Copying）算法：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当一块内存用完了，就将还存活着的对象复制到另外一块上，然后清理掉前一块。

每次对半区内存回收时、内存分配时就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

缺点：将内存缩小为一半，性价比低，持续复制长生存期的对象则导致效率低下。

JVM堆中新生代便采用复制算法。回到最初推分配结构图。

在GC回收过程中，当Eden区满时，还存活的对象会被复制到其中一个Survivor区；当回收时，会将Eden和使用的Survivor区还存活的对象，复制到另外一个Survivor区，然后对Eden和用过的Survivor区进行清理。

如果另外一个Survivor区没有足够的内存存储时，则会进入老年代。

这里针对哪些对象会进入老年代有这样的机制：对象每经历一次复制，年龄加1，达到晋升年龄阈值后，转移到老年代。

在这整个过程中，由于Eden中的对象属于像浮萍一样“瞬生瞬灭”的对象，所以并不需要1：1的比例来分配内存，而是采用了8：1：1的比例来分配。

而针对那些像“水熊虫”一样，历经多次清理依旧存活的对象，则会进入老年代，而老年的清理算法则采用下面要讲到的“标记整理算法”。

标记整理算法

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

 

这种算法不既不用浪费50%的内存，也解决了复制算法在对象存活率较高时的效率低下问题。

分代收集算法

分代收集算法，基本思路：将Java的堆内存逻辑上分成两块，新生代和老年代，针对不同存活周期、不同大小的对象采取不同的垃圾回收策略。

而在新生代中大多数对象都是瞬间对象，只有少量对象存活，复制较少对象即可完成清理，因此采用复制算法。而针对老年代中的对象，存活率较高，又没有额外的担保内存，因此采用标记整理算法。

其实，回头看，分代收集算法就是对新生代和老年代算法从策略维度的规划而已。

 

G1垃圾收集器并非横空出世，早在JDK1.7的时候就已经存在了。随着后续的优化，终于在JDK1.9的时候被Oracle付以重任，替换CMS成为默认的垃圾收集器。

G1相较于CMS的显著特点是，减少了空间碎片。CMS的空间碎片很严重，Mark-Sweep之后的空间，有很多小碎片，但是都比要分配的小，然后触发一次Full GC，让人崩溃。

一、啥是G1垃圾收集器

Garbage-First（G1，垃圾优先）收集器是服务类型的收集器，目标是多处理器机器、大内存机器。它高度符合垃圾收集暂停时间的目标，同时实现高吞吐量。Oracle JDK 7 update 4 以及更新发布版完全支持G1垃圾收集器。G1垃圾回集器为以下应用设计：

类似CMS收集器，可以和应用线程同时并发的执行压缩空闲空间时没有GC引起的暂停时间需要更可预言的GC暂停时间不想牺牲大量的吞吐量性能不需要特别大的Java堆

 

G1垃圾收集器计划长期替换并发标记清除收集器（CMS，Concurrent Mark-Sweep Collector）。G1和CMS比较，有一些不同点让G1成为一个更好的解决方案。一个不同点是G1是一个压缩收集器。G1收集器充分地压缩空间以完全避免分配空间使用细粒度的空闲列表，而不是依赖于区块。这相当简化了收集器的部件，和尽量消除可能的碎片问题。同时，G1收集器相比CMS收集器而方言，提供更可预言的垃圾收集暂停时间，允许用户指定想要暂停时间指标。

二、G1如何进行垃圾收集

老的垃圾收集器都把堆结构化为三个部分：年轻代、年老代和永久代（或元数据区）。 G1则采用了新的结构，堆空间被分割成一些相同大小的堆区域，每一个都是连续范围的虚拟内存。特定的区域集合像旧的收集器一样被指派为相同的角色（伊甸：eden、幸存：survivor、年老：old），但是它们没有一个固定大小。这在内存使用上提供了更强大的灵活性。

 

当执行垃圾收集时，G1收集器以与CMS收集器类似的方式操作。G1收集器执行一个全局的并发标记阶段来决定堆中的对象的活跃度。之后标记阶段就完成了。G1收集器知道哪个区域基本上是空的。它首先会收集那些产出大量空闲空间的区域。这就是为什么这个垃圾收集的方法叫做垃圾优先的原因。就像名称显示的那样，G1收集器集中它的收集和压缩活动在堆里的那些可完全被回收的区域，那就是垃圾。G1收集器使用一个暂停预言的模式去达到一个用户定义的暂停时间指标，基于用户指定的暂停时间指标去选择收集区域的数量。

被G1收集器鉴定为可以回收的区域就是垃圾，使用抽空的方式收集。G1收集器从堆空间的一个或多个区域里复制对象到堆空间的一个单独的区域内，这个过程中同时压缩和释放内存。这个抽空过程在多处理上以并行的方式运行，以减小暂停时间和增加吞吐量。因此，每一次垃圾收集G1收集器连续不断地去减少碎片，在用户指定的暂停时间内工作。这超越了以往方法的能力。并发标记-清除（CMS，Concurrent Mark Sweep）垃圾收集器不做压缩操作。并行年老代（ParallelOld）垃圾收集只进行整个堆的压缩，会导致相当大的暂停时间。

注意：G1收集器不是实时的收集器非常重要。它在很大程度上符合用户设定的暂停时间指标但是并不绝对符合。基于前面垃圾收集的数据来看，G1收集器会估算在用户指定的时间指标能收集多少区域。因此，收集器有一个合理的精确的收集这些区域的代价模型，它使用这个模型决定在用户指定的暂停时间内收集哪些、多少个区域。

• 初始标记：标记一下GC Roots能直接关联到的对象，需要停顿线程，但耗时很短
• 并发标记：是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
• 最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录
• 筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划

三、适合G1垃圾收集的场景

G1收集器首要关注的是为用户运行着需要大堆空间、限制的垃圾回收延迟的应用提供一个解决方案。这意味着堆大小为6GB左右或者更大，稳定的、可预言的暂停时间小于0.5秒。

如果应用有以下一个或多个特点，当下运行着CMS或ParallelOldGC垃圾收集器的应用把收集器切换到G1收集器的话，会从中受益的：

Full GC持续时间太长或者太频繁对象分配比率或者提升有显著的变化不期望的长时间垃圾收集或者压缩暂停（大于0.5到1秒）现实项目中，大家可以根据实际情况具体选择