深入理解Java虚拟机-垃圾回收器与内存分配策略

怼烎@ 2022-12-07 12:29 204阅读 0赞

### 目录 ###

*  概述
 *  哪些内存需要回收-回收算法
 *   *  引用计数法
     *  可达性分析算法
     *   *  哪些可作为GC Roots
 *  四大引用
 *  方法区(永久代)回收
 *  垃圾收集算法
 *   *  标记-清除算法
     *  复制算法
     *  标记-整理算法
 *  分代收集算法
 *   *  新生代（Young generation）
     *  老年代（Old generation）
     *  永久代（permanent generation）
 *  小结
 *  不同的垃圾收集算法
 *   *  新生代
     *  老年代
     *  结论
 *  HotSpot的算法实现
 *   *  枚举根节点
 *  垃圾收集器
 *  垃圾回收器分类标准
 *  七种垃圾回收器概述
 *   *  单线程垃圾回收器
     *   *  Serial（-XX:+UseSerialGC）
         *  Serial Old（-XX:+UseSerialGC）
     *  多线程垃圾回收器（吞吐量优先）
     *   *  ParNew（-XX:+UseParNewGC）
         *  Parallel Old（-XX:+UseParallelOldGC）
     *  其他的回收器（停顿时间优先）
     *   *  CMS（-XX:+UseConcMarkSweepGC）

# 概述 #

说起垃圾收集（Garbage Collection，GC），大部分人都把这项技术当作Java语言的伴生产物。事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的3件事情：

*  哪些内存需要回收？
 *  什么时候回收？
 *  如何回收？  
    经过半个多世纪的发展，目前内存的动态分配与内存回收技术已经相当成熟，一切看起来都进入了"自动化"时代，那为什么我们还要去了解GC和内存分配？答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些"自动化"的技术实施必要的监控和调节。

# 哪些内存需要回收-回收算法 #

## 引用计数法 ##

java堆中每个对象都有一个引用计数器,当一个对象被创建并被初始化赋值时,该变量的计数设置为1,每当有一个地方引用,该计数器就加1,当引用失效时,该计数器就减1, 当引用计数变为0时,可以被当做垃圾

*  优点  
    引用计数收集器执行简单，判定效率高，交织在程序运行中。对程序不被长时间打断的实时环境比较有利。
 *  缺点:  
    难以检测出对象之间的循环引用。同时，引用计数器增加了程序执行的开销。所以Java语言并没有选择这种算法进行垃圾回收

## 可达性分析算法 ##

可达性分析算法又叫跟搜索算法, 该算法是通过一系列称为\[GC Roots\] 的对象作为起点,  
从这些起始点开始搜索,搜索说过的路径叫 引用链 ,当一个对象到GC roots之前没哟任何引用链的时候, 该对象是不可用的可以被回收

### 哪些可作为GC Roots ###

*  虚拟机栈中局部变量表
 *  方法区中静态变量引用的对象
 *  方法区中常量引用的对象
 *  本地方法栈中JNI(Native方法)引用的对象

# 四大引用 #

在 Java 中，根据引用关系的强弱不一样，将引用类型划为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。

*  **强引用**：Object obj = new Object()这种方式就是强引用，只要这种强引用存在，垃圾收集器就永远不会回收被引用的对象。
 *  **软引用**：用来描述一些有用但非必须的对象。在 OOM 之前垃圾收集器会把这些被软引用的对象列入回收范围进行二次回收。如果本次回收之后还是内存不足才会触发 OOM。在 Java 中使用 SoftReference 类来实现软引用。
 *  **弱引用**：同软引用一样也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在 Java 中使用 WeakReference 类来实现。
 *  **虚引用**：是最弱的一种引用关系，一个对象是否有虚引用的存在完全不影响对象的生存时间，也无法通过虚引用来获取一个对象的实例。一个对象使用虚引用的唯一目的是为了在被垃圾收集器回收时收到一个系统通知。在 Java 中使用 PhantomReference 类来实现

# 方法区(永久代)回收 #

回收方法区  
前面介绍过，方法区在 HotSpot 虚拟机中被划分为永久代。在 Java 虚拟机规范中没有要求方法区实现垃圾收集，而且方法区垃圾收集的性价比也很低。

方法区（永久代）的垃圾收集主要回收两部分内容：废弃常量和无用的类。

废弃常量的回收和 Java 堆中对象的回收非常类似，这里就不做过多的解释了。

类的回收条件就比较苛刻了。要判定一个类是否可以被回收，要满足以下三个条件：

*  该类的所有实例已经被回收；
 *  加载该类的 ClassLoader 已经被回收；
 *  该类的 Class 对象没有被引用，无法再任何地方通过反射访问该类的方法。

# 垃圾收集算法 #

## 标记-清除算法 ##

发生区域:Eden区  
标记-清除算法（Mark-Sweep）是一种常见的基础垃圾收集算法，它将垃圾收集分为两个阶段：

标记阶段：标记出可以回收的对象。  
清除阶段：回收被标记的对象所占用的空间。  
标记-清除算法之所以是基础的，是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。

*  优点：实现简单，不需要对象进行移动。
 *  缺点：标记、清除过程效率低，产生大量不连续的内存碎片，提高了垃圾回收的频率。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center]

## 复制算法 ##

为了解决标记-清除算法的效率不高的问题，产生了复制算法。它把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾收集时，遍历当前使用的区域，把存活对象复制到另外一个区域中，最后将当前使用的区域的可回收的对象进行回收。

*  优点：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。
 *  缺点：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

复制算法的执行过程如下图所示:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 1]

现在的商业虚拟机都采用这种算法来回收新生代，在 IBM 的研究中新生代中的对象 98% 都是「朝生夕死」，所以并不需要按照 1:1 的比例来划分空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。 HotSpot 默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用的内存为整个新生代容量的 90%（80%+10%），只有 10% 会被浪费。当然，98% 的对象可回收只是一般场景下的数据，我们没办法保证每次回收后都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其它内存（这里指老年代）进行分配担保。如果另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来存活的对象时，这些对象将直接通过分配担保机制进入老年代

## 标记-整理算法 ##

在新生代中可以使用复制算法，但是在老年代就不能选择复制算法了，因为老年代的对象存活率会较高，这样会有较多的复制操作，导致效率变低。标记-清除算法可以应用在老年代中，但是它效率不高，在内存回收后容易产生大量内存碎片。因此就出现了一种标记-整理算法（Mark-Compact）算法，与标记-整理算法不同的是，在标记可回收的对象后将所有存活的对象压缩到内存的一端，使他们紧凑的排列在一起，然后对端边界以外的内存进行回收。回收后，已用和未用的内存都各自一边。

*  优点：解决了标记-清理算法存在的内存碎片问题。
 *  缺点：仍需要进行局部对象移动，一定程度上降低了效率。

标记-整理算法的执行过程如下图所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 2]

# 分代收集算法 #

当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法，顾名思义是根据对象的存活周期将内存划分为几块。一般包括年轻代、老年代 和 永久代，如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 3]

## 新生代（Young generation） ##

绝大多数最新被创建的对象会被分配到这里，由于大部分对象在创建后会很快变得不可达，所以很多对象被创建在新生代，然后消失。对象从这个区域消失的过程我们称之为 minor GC。

**新生代** 中存在一个Eden区和两个Survivor区。新对象会首先分配在Eden中（如果新对象过大，会直接分配在老年代中）。在GC中，Eden中的对象会被移动到Survivor中，直至对象满足一定的年纪（定义为熬过GC的次数），会被移动到老年代。

可以设置新生代和老年代的相对大小。这种方式的优点是新生代大小会随着整个堆大小动态扩展。参数 -XX:NewRatio 设置老年代与新生代的比例。例如 -XX:NewRatio=8 指定 老年代/新生代 为8/1. 老年代 占堆大小的 7/8 ，新生代 占堆大小的 1/8（默认即是 1/8）。

例如：

-XX:NewSize=64m -XX:MaxNewSize=1024m -XX:NewRatio=8

## 老年代（Old generation） ##

对象没有变得不可达，并且从新生代中存活下来，会被拷贝到这里。其所占用的空间要比新生代多。也正由于其相对较大的空间，发生在老年代上的GC要比新生代要少得多。对象从老年代中消失的过程，可以称之为major GC（或者full GC）。

## 永久代（permanent generation） ##

像一些类的层级信息，方法数据 和方法信息（如字节码，栈 和 变量大小），运行时常量池（JDK7之后移出永久代），已确定的符号引用和虚方法表等等。它们几乎都是静态的并且很少被卸载和回收，在JDK8之前的HotSpot虚拟机中，类的这些**永久的** 数据存放在一个叫做永久代的区域。

永久代一段连续的内存空间，我们在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小。但是JDK8之后取消了永久代，这些元数据被移到了一个与堆不相连的称为元空间 (Metaspace) 的本地内存区域。

# 小结 #

当执行一次Minor Collection时，Eden空间的存活对象会被复制到To Survivor空间，并且之前经过一次Minor Collection并在From Survivor空间存活的仍年轻的对象也会复制到To Survivor空间。  
有两种情况Eden空间和From Survivor空间存活的对象不会复制到To Survivor空间，而是晋升到老年代。一种是存活的对象的分代年龄超过-XX:MaxTenuringThreshold（用于控制对象经历多少次Minor GC才晋升到老年代）所指定的阈值。另一种是To Survivor空间容量达到阈值。  
当所有存活的对象被复制到To Survivor空间，或者晋升到老年代，也就意味着Eden空间和From Survivor空间剩下的都是可回收对象，如下图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 4]  
这时GC执行Minor Collection，Eden空间和From Survivor空间都会被清空，而存活的对象都存放在To Survivor空间。  
接下来将From Survivor空间和To Survivor空间互换位置，也就是此前的From Survivor空间成为了现在的To Survivor空间，每次Survivor空间互换都要保证To Survivor空间是空的，这就是复制算法在新生代中的应用。在老年代则采用了标记-压缩算法。

# 不同的垃圾收集算法 #

## 新生代 ##

对于新生代，每次GC时都有大量的对象死亡，只有少量对象存活。考虑到复制成本低，适合采用复制算法。因此有了From Survivor和To Survivor区域。

## 老年代 ##

对于老年代，因为对象存活率高，没有额外的内存空间对它进行担保。因而适合采用标记-清理算法和标记-整理算法进行回收。

## 结论 ##

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。垃圾回收有两种类型，Minor GC 和 Full GC。

*  Minor GC：新生代垃圾收集。对新生代进行回收，不会影响到年老代。因为新生代的 Java 对象大多死亡频繁，所以 Minor GC 非常频繁，一般在这里使用速度快、效率高的算法，使垃圾回收能尽快完成。
 *  Full GC：也叫 Major GC，对整个堆进行回收，包括新生代和老年代（JDK8 取消永久代）。由于Full GC需要对整个堆进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。它的收集频率较低，耗时较长。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 5]

# HotSpot的算法实现 #

## 枚举根节点 ##

*  可达性分析枚举GC Roots时 ，必须stop the world
 *  目前JVM使用准确式GC，停顿时并不需要一个个检查，而是从预先存放的地方直接取。（HotSpot保存在OopMap数据结构中）

# 垃圾收集器 #

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器，其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括Serial Old、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。不同收集器之间的连线表示它们可以搭配使用。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 6]

*  Serial收集器（复制算法): 新生代单线程收集器，标记和清理都是单线程，优点是简单高效；
 *  ParNew收集器 (复制算法): 新生代并行收集器，实际上是Serial收集器的多线程版本，在多核CPU环境下有着比Serial更好的表现；
 *  Parallel Scavenge收集器 (复制算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量 = 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间，尽快完成程序的运算任务，适合后台应用等对交互相应要求不高的场景；
 *  Serial Old收集器 (标记-整理算法): 老年代单线程收集器，Serial收集器的老年代版本；
 *  Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先，Parallel Scavenge收集器的老年代版本；
 *  CMS(Concurrent Mark Sweep)收集器（标记-清除算法）： 老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。
 *  G1(Garbage First)收集器 (标记-整理算法)： Java堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。此外，G1收集器不同于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代。

# 垃圾回收器分类标准 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 7]

# 七种垃圾回收器概述 #

在 JVM 中，具体实现有 Serial、ParNew、Parallel Scavenge、CMS、Serial Old（MSC）、Parallel Old、G1 等。在下图中，你可以看到 不同垃圾回收器 适合于 不同的内存区域，如果两个垃圾回收器之间 存在连线，那么表示两者可以 配合使用。

如果当 垃圾回收器 进行垃圾清理时，必须 暂停 其他所有的 工作线程，直到它完全收集结束。我们称这种需要暂停工作线程才能进行清理的策略为 Stop-the-World。以上回收器中， Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old 均采用的是 Stop-the-World 的策略。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 8]  
图中有 7 种不同的 垃圾回收器，它们分别用于不同分代的垃圾回收。

*  新生代回收器：Serial、ParNew、Parallel Scavenge
 *  老年代回收器：Serial Old、Parallel Old、CMS
 *  整堆回收器：G1

## 单线程垃圾回收器 ##

### Serial（-XX:+UseSerialGC） ###

Serial 回收器是最基本的 新生代 垃圾回收器，是 单线程 的垃圾回收器。由于垃圾清理时，Serial 回收器 不存在 线程间的切换，因此，特别是在单 CPU 的环境下，它的 垃圾清除效率 比较高。对于 Client 运行模式的程序，选择 Serial 回收器是一个不错的选择。

> Serial 新生代回收器 采用的是 复制算法。

### Serial Old（-XX:+UseSerialGC） ###

Serial Old 回收器是 Serial 回收器的 老生代版本，属于 单线程回收器，它使用 标记-整理 算法。对于 Server 模式下的虚拟机，在 JDK1.5 及其以前，它常与 Parallel Scavenge 回收器配合使用，达到较好的 吞吐量，另外它也是 CMS 回收器在 Concurrent Mode Failure 时的 后备方案。

Serial 回收器和 Serial Old 回收器的执行效果如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 9]

> Serial Old 老年代回收器 采用的是 标记 - 整理算法。

## 多线程垃圾回收器（吞吐量优先） ##

### ParNew（-XX:+UseParNewGC） ###

ParNew 回收器是在 Serial 回收器的基础上演化而来的，属于 Serial 回收器的 多线程版本，同样运行在 新生代区域。在实现上，两者共用很多代码。在不同运行环境下，根据 CPU 核数，开启 不同的线程数，从而达到 最优 的垃圾回收效果。对于那些 Server 模式的应用程序，如果考虑采用 CMS 作为 老生代回收器 时，ParNew 回收器是一个不错的选择。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 10]

> ParNew 新生代回收器 采用的是 复制算法。

### Parallel Old（-XX:+UseParallelOldGC） ###

Parallel Old 回收器是 Parallel Scavenge 回收器的 老生代版本，属于 多线程回收器，采用 标记-整理算法。Parallel Old 回收器和 Parallel Scavenge 回收器同样考虑了 吞吐量优先 这一指标，非常适合那些 注重吞吐量 和 CPU 资源敏感 的场合

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 11]

> Parallel Old 老年代回收器 采用的是 标记 - 整理算法。

## 其他的回收器（停顿时间优先） ##

### CMS（-XX:+UseConcMarkSweepGC） ###

CMS（Concurrent Mark Sweep） 回收器是在 最短回收停顿时间 为前提的回收器，属于 多线程回收器，采用 标记-清除算法。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 12]  
相比之前的回收器，CMS 回收器的运作过程比较复杂，分为四步：

初始标记（CMS initial mark）  
初始标记 仅仅是标记 GC Roots 内 直接关联 的对象。这个阶段 速度很快，需要 Stop the World。

相比之前的回收器，CMS 回收器的运作过程比较复杂，分为四步：

*  初始标记（CMS initial mark）  
    初始标记 仅仅是标记 GC Roots 内 直接关联 的对象。这个阶段 速度很快，需要 Stop the World。
 *  并发标记（CMS concurrent mark）  
    并发标记 进行的是 GC Tracing，从 GC Roots 开始对堆进行 可达性分析，找出 存活对象。
 *  重新标记（CMS remark）  
    重新标记 阶段为了 修正 并发期间由于 用户进行运作 导致的 标记变动 的那一部分对象的 标记记录。这个阶段的 停顿时间 一般会比 初始标记阶段 稍长一些，但远比 并发标记 的时间短，也需要 Stop The World。
 *  并发清除（CMS concurrent sweep）  
    并发清除 阶段会清除垃圾对象。

> 初始标记（CMS initial mark）和 重新标记（CMS remark）会导致 用户线程 卡顿，Stop the World  
> 现象发生。

在整个过程中，CMS 回收器的 内存回收 基本上和 用户线程 并发执行，如下所示：

由于 CMS 回收器 并发收集、停顿低，因此有些地方成为 并发低停顿回收器（Concurrent Low Pause Sweep Collector）。  
CMS 回收器的缺点：

CMS回收器对CPU资源非常依赖  
CMS 回收器过分依赖于 多线程环境，默认情况下，开启的 线程数 为（CPU 的数量 + 3）/ 4，当 CPU 数量少于 4 个时，CMS 对 用户查询 的影响将会很大，因为他们要分出一半的运算能力去 执行回收器线程；

CMS回收器无法清除浮动垃圾  
由于 CMS 回收器 清除已标记的垃圾 （处于最后一个阶段）时，用户线程 还在运行，因此会有新的垃圾产生。但是这部分垃圾 未被标记，在下一次 GC 才能清除，因此被成为 浮动垃圾。

由于 内存回收 和 用户线程 是同时进行的，内存在被 回收 的同时，也在被 分配。当 老生代 中的内存使用超过一定的比例时，系统将会进行 垃圾回收；当 剩余内存 不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时采用 Serial Old 算法进行 清除，此时的 性能 将会降低。

垃圾收集结束后残余大量空间碎片  
CMS 回收器采用的 标记清除算法，本身存在垃圾收集结束后残余 大量空间碎片 的缺点。CMS 配合适当的 内存整理策略，在一定程度上可以解决这个问题。

G1回收器（垃圾区域Region优先）  
G1 是 JDK 1.7 中正式投入使用的用于取代 CMS 的 压缩回收器。它虽然没有在物理上隔断 新生代 与 老生代，但是仍然属于 分代垃圾回收器。G1 仍然会区分 年轻代 与 老年代，年轻代依然分有 Eden 区与 Survivor 区。

G1 首先将 堆 分为 大小相等 的 Region，避免 全区域 的垃圾回收。然后追踪每个 Region 垃圾 堆积的价值大小，在后台维护一个 优先列表，根据允许的回收时间优先回收价值最大的 Region。同时 G1采用 Remembered Set 来存放 Region 之间的 对象引用 ，其他回收器中的 新生代 与 老年代 之间的对象引用，从而避免 全堆扫描。G1 的分区示例如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 13]  
这种使用 Region 划分 内存空间 以及有 优先级 的区域回收方式，保证 G1 回收器在有限的时间内可以获得尽可能 高的回收效率。

G1 和 CMS 运作过程有很多相似之处，整个过程也分为 4 个步骤：

1.初始标记（CMS initial mark）

初始标记 仅仅是标记 GC Roots 内 直接关联 的对象。这个阶段 速度很快，需要 Stop the World。

2.并发标记（CMS concurrent mark）

并发标记 进行的是 GC Tracing，从 GC Roots 开始对堆进行 可达性分析，找出 存活对象。

3.重新标记（CMS remark）

重新标记 阶段为了 修正 并发期间由于 用户进行运作 导致的 标记变动 的那一部分对象的 标记记录。这个阶段的 停顿时间 一般会比 初始标记阶段 稍长一些，但远比 并发标记 的时间短，也需要 Stop The World。

4.筛选回收

首先对各个 Region 的 回收价值 和 成本 进行排序，根据用户所期望的 GC 停顿时间 来制定回收计划。这个阶段可以与用户程序一起 并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿 用户线程 将大幅提高回收效率。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 14]  
与其它 GC 回收相比，G1 具备如下 4 个特点：

*  并行与并发  
    使用多个 CPU 来缩短 Stop-the-World 的 停顿时间，部分其他回收器需要停顿 Java 线程执行的 GC 动作，G1 回收器仍然可以通过 并发的方式 让 Java 程序继续执行。
 *  分代回收  
    与其他回收器一样，分代概念 在 G1 中依然得以保留。虽然 G1 可以不需要 其他回收器配合 就能独立管理 整个GC堆，但它能够采用 不同的策略 去处理 新创建的对象 和 已经存活 一段时间、熬过多次 GC 的旧对象，以获取更好的回收效果。新生代 和 老年代 不再是 物理隔离，是多个 大小相等 的独立 Region。
 *  空间整合  
    与 CMS 的 标记—清理 算法不同，G1 从 整体 来看是基于 标记—整理 算法实现的回收器。从 局部（两个 Region 之间）上来看是基于 复制算法 实现的。

但无论如何，这 两种算法 都意味着 G1 运作期间 不会产生内存空间碎片，回收后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象 时不会因为无法找到 连续内存空间 而提前触发 下一次 GC。

*  可预测的停顿  
    这是 G1 相对于 CMS 的另一大优势，降低停顿时间 是 G1 和 CMS 共同的关注点。G1 除了追求 低停顿 外，还能建立 可预测 的 停顿时间模型，能让使用者明确指定在一个 长度 为 M 毫秒的 时间片段 内，消耗在 垃圾回收 上的时间不得超过 N 毫秒。（后台维护的 优先列表，优先回收 价值大 的 Region）。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/cc353919486945f8a31607a656b71326.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/cead1d3fc9f94ee2a2203b5268b18ec8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/be7c5b1fd2984d1883e32935cef7196e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/5b7aa10df2a840bf8dede2df337031bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/5299793b371c4df1a0e1bbf670cffbac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/f65722ff46cd45bfa66e76c668b51e6a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/64f3ecba5b8e47b9b0e7fefe40214c36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/5cfbca3fe62045388b2207e2c43d3bd3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/b29be45d04f945babd1ab452d5afd8e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/0ffcfef3e02d4b63ada82c9b115efd56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221123/9739b8bcd6d74d37ab452e8f25e0b91c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221123/29f1e69291444e20a93d6b6122a00bce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221123/033f151add0c4fe58b1191e2f9662fc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221123/692e3d5c98f04a349849e71f97883763.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbmlhbjIwMTY_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221123/a1a0e3055e9b4a108505323253f651a1.png