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

浅浅的花香味﹌ 2021-09-21 01:40 338阅读 0赞

> 本博客主要参考周志明老师的《深入理解Java虚拟机》第二版

读书是一种跟大神的交流。阅读《深入理解Java虚拟机》受益匪浅，对Java虚拟机有初步的认识。这里写博客主要出于以下三个目的：一方面是记录，方便日后阅读；一方面是加深对内容的理解；一方面是分享给大家，希望对大家有帮助。

《深入理解Java虚拟机》全书总结如下：

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>内容</th> 
   <th>链接地址</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>深入理解Java虚拟机-走近Java</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103804387" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103804387</a></td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>深入理解Java虚拟机-Java内存区域与内存溢出异常</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103827387" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103827387</a></td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>深入理解Java虚拟机-垃圾回收器与内存分配策略</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103831676" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103831676</a></td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>深入理解Java虚拟机-虚拟机执行子系统</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103835168" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103835168</a></td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>深入理解Java虚拟机-程序编译与代码优化</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103835883" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103835883</a></td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>深入理解Java虚拟机-高效并发</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103836167" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103836167</a></td> 
  </tr> 
 </tbody> 
</table>

### 文章目录 ###

*   *   *  概述
         *  对象已死吗
         *   *  引用计数法
             *  可达性分析算法
             *  再谈引用
             *  生存还是死亡
             *  回收方法区
         *  垃圾收集算法
         *   *  标记-清除算法
             *  复制算法
             *  标记-整理算法
             *  分代收集算法
             *   *  新生代（Young generation）
                 *  老年代（Old generation）
                 *  永久代（permanent generation）
                 *  小结
             *  垃圾收集算法小结
         *  HotSpot的算法实现
         *   *  枚举根节点
             *  安全点
             *  安全区域
         *  垃圾收集器
         *   *  垃圾回收器分类标准
             *  七种垃圾回收器概述
             *  单线程垃圾回收器
             *   *  Serial（-XX:+UseSerialGC）
                 *  Serial Old（-XX:+UseSerialGC）
             *  多线程垃圾回收器（吞吐量优先）
             *   *  ParNew（-XX:+UseParNewGC）
                 *  Parallel Scavenge（-XX:+UseParallelGC）
                 *  Parallel Old（-XX:+UseParallelOldGC）
             *  其他的回收器（停顿时间优先）
             *   *  CMS（-XX:+UseConcMarkSweepGC）
                 *  G1回收器（垃圾区域Region优先）
         *  内存分配与回收策略
         *   *  对象优先在 Eden 区分配
             *  大对象直接进入老年代
             *  长期存活对象将进入老年代
             *  动态对象年龄判定
             *  空间分配担保
         *  本章小结

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

### 概述 ###

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

*  哪些内存需要回收？
 *  什么时候回收？
 *  如何回收？

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

### 对象已死吗 ###

垃圾收集器在做垃圾回收的时候，首先需要判定的就是哪些内存是需要被回收的，哪些对象是「存活」的，是不可以被回收的；哪些对象已经「死掉」了，需要被回收。

#### 引用计数法 ####

`Java` **堆** 中每个具体对象（**不是引用**）都有一个**引用计数器**。当一个对象被创建并初始化赋值后，该变量计数设置为`1`。每当有一个地方引用它时，计数器值就**加1**。当引用**失效**时，即一个对象的某个引用超过了生命周期（出作用域后）或者被设置为一个新值时，计数器值就**减1**。任何引用计数为`0`的对象可以被当作**垃圾收集**。当一个对象被垃圾收集时，它引用的任何对象计数减1。

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

#### 可达性分析算法 ####

可达性分析算法又叫根搜索算法，该算法的基本思想就是通过一系列称为「GC Roots」的对象作为起始点，从这些起始点开始往下搜索，搜索所走过的路径称为引用链，当一个对象到 GC Roots 对象之间没有任何引用链的时候（不可达），证明该对象是不可用的，于是就会被判定为可回收对象。

如下图所示: `Object5`、`Object6`、`Object7` 虽然互有关联, 但它们到`GC Roots`是不可达的, 因此也会被判定为可回收的对象。

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

在 Java 中可作为 GC Roots 的对象包含以下几种：

*  虚拟机栈（栈帧中的本地变量表）中引用的对象；
 *  方法区中类静态属性引用的对象；
 *  方法区中常量引用的对象；
 *  本地方法栈中 JNI（Native 方法）引用的对象。

JVM中用到的所有现代GC算法在回收前都会先找出所有仍存活的对象。可达性分析算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图。下图展示的JVM中的内存布局可以用来很好地阐释这一概念：

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

#### 再谈引用 ####

无论是通过引用计数器还是通过可达性分析来判断对象是否可以被回收都设计到「引用」的概念。在 Java 中，根据引用关系的强弱不一样，将引用类型划为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。

**强引用**：`Object obj = new Object()`这种方式就是强引用，只要这种强引用存在，垃圾收集器就永远不会回收被引用的对象。

**软引用**：用来描述一些有用但非必须的对象。在 OOM 之前垃圾收集器会把这些被软引用的对象列入回收范围进行二次回收。如果本次回收之后还是内存不足才会触发 OOM。在 Java 中使用 SoftReference 类来实现软引用。

**弱引用**：同软引用一样也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在 Java 中使用 WeakReference 类来实现。

**虚引用**：是最弱的一种引用关系，一个对象是否有虚引用的存在完全不影响对象的生存时间，也无法通过虚引用来获取一个对象的实例。一个对象使用虚引用的唯一目的是为了在被垃圾收集器回收时收到一个系统通知。在 Java 中使用 PhantomReference 类来实现。

#### 生存还是死亡 ####

一个对象是否应该在垃圾回收器在`GC`时回收，至少要经历**两次标记过程**。

**第一次标记**：如果对象在进行可达性分析后被判定为不可达对象，那么它将被第一次标记并且进行一次筛选。筛选的条件是此对象是否有必要执行 finalize() 方法。对象没有覆盖 finalize() 方法或者该对象的 finalize() 方法曾经被虚拟机调用过，则判定为没必要执行。

**finalize()第二次标记**：如果被判定为有必要执行 finalize() 方法，那么这个对象会被放置到一个 F-Queue 队列中，并在稍后由虚拟机自动创建的、低优先级的 Finalizer 线程去执行该对象的 finalize() 方法。但是虚拟机并不承诺会等待该方法结束，这样做是因为，如果一个对象的 finalize() 方法比较耗时或者发生了死循环，就可能导致 F-Queue 队列中的其他对象永远处于等待状态，甚至导致整个内存回收系统崩溃。finalize() 方法是对象逃脱死亡命运的最后一次机会，如果对象要在 finalize() 中挽救自己，只要重新与 GC Roots 引用链关联上就可以了。这样在第二次标记时它将被移除「即将回收」的集合，如果对象在这个时候还没有逃脱，那么它基本上就真的被回收了。

#### 回收方法区 ####

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

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

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

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

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

### 垃圾收集算法 ###

#### 标记-清除算法 ####

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

*  标记阶段：标记出可以回收的对象。
 *  清除阶段：回收被标记的对象所占用的空间。

标记-清除算法之所以是基础的，是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。

**优点**：实现简单，不需要对象进行移动。

**缺点**：标记、清除过程效率低，产生大量不连续的内存碎片，提高了垃圾回收的频率。

标记-清除算法的执行的过程如下图所示

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

#### 复制算法 ####

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

**优点**：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。

**缺点**：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

复制算法的执行过程如下图所示

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

现在的商业虚拟机都采用这种算法来回收新生代，在 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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 4]

#### 分代收集算法 ####

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

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

##### 新生代（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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 6]

这时GC执行Minor Collection，Eden空间和From Survivor空间都会被清空，而存活的对象都存放在To Survivor空间。  
接下来将From Survivor空间和To Survivor空间互换位置，也就是此前的From Survivor空间成为了现在的To Survivor空间，每次Survivor空间互换都要保证To Survivor空间是空的，这就是复制算法在新生代中的应用。在老年代则采用了标记-压缩算法。

`JDK8`堆内存一般是划分为**年轻代**和**老年代**，**不同年代** 根据自身特性采用**不同的垃圾收集算法**。

对于**新生代**，每次`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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 7]

### HotSpot的算法实现 ###

#### 枚举根节点 ####

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

#### 安全点 ####

*  基于效率考虑，生成OopMap只会才特定的地方，称为安全点
 *  安全点的选定方法
    
     *  抢先式中断：现代JVM不采用
     *  主动式中断：线程轮询安全点标识，然后挂起

#### 安全区域 ####

*  对于没有分配cpu的线程（sleep），安全点无法处理，由安全区域解决
 *  安全区域指一段代码中引用关系不会发生变化
 *  线程进入安全区域时，JVM发起GC就不用管这些线程，离开时需要检查GC是否完成，未完成就需要等待

### 垃圾收集器 ###

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

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

*  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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 9]

#### 七种垃圾回收器概述 ####

在 `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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 8]

图中有 `7` 种不同的 **垃圾回收器**，它们分别用于不同分代的垃圾回收。

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

两个 **垃圾回收器** 之间有连线表示它们可以 **搭配使用**，可选的搭配方案如下：

<table> 
 <thead> 
  <tr> 
   <th align="left">新生代</th> 
   <th align="left">老年代</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">Serial</td> 
   <td align="left">Serial Old</td> 
  </tr> 
  <tr> 
   <td align="left">Serial</td> 
   <td align="left">CMS</td> 
  </tr> 
  <tr> 
   <td align="left">ParNew</td> 
   <td align="left">Serial Old</td> 
  </tr> 
  <tr> 
   <td align="left">ParNew</td> 
   <td align="left">CMS</td> 
  </tr> 
  <tr> 
   <td align="left">Parallel Scavenge</td> 
   <td align="left">Serial Old</td> 
  </tr> 
  <tr> 
   <td align="left">Parallel Scavenge</td> 
   <td align="left">Parallel Old</td> 
  </tr> 
  <tr> 
   <td align="left">G1</td> 
   <td align="left">G1</td> 
  </tr> 
 </tbody> 
</table>

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

##### 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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 10]

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

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

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

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

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

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

##### Parallel Scavenge（-XX:+UseParallelGC） #####

和 `ParNew` 回收一样，`Parallel Scavenge` 回收器也是运行在 **新生代区域**，属于 **多线程** 的回收器。但不同的是，`ParNew` 回收器是通过控制 **垃圾回收** 的 **线程数** 来进行参数调整，而 `Parallel Scavenge` 回收器更关心的是 **程序运行的吞吐量**。即一段时间内，**用户代码** 运行时间占 **总运行时间** 的百分比。

> `Parallel Scavenge` **新生代回收器** 采用的是 **复制算法**。

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

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

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

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

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

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

`CMS（Concurrent Mark Sweep）` 回收器是在 **最短回收停顿时间** 为前提的回收器，属于 **多线程回收器**，采用 **标记-清除算法**。

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

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

1.  **初始标记（CMS initial mark）**

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

1.  **并发标记（CMS concurrent mark）**

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

1.  **重新标记（CMS remark）**

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

1.  **并发清除（CMS concurrent sweep）**

**并发清除** 阶段会清除垃圾对象。

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

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

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

`CMS` 回收器的缺点：

1.  **CMS回收器对CPU资源非常依赖**

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

1.  **CMS回收器无法清除浮动垃圾**

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

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

1.  **垃圾收集结束后残余大量空间碎片**

`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_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 14]

这种使用 `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）

4.筛选回收

首先对各个 `Region` 的 **回收价值** 和 **成本** 进行排序，根据用户所期望的 `GC` **停顿时间** 来制定回收计划。这个阶段可以与用户程序一起 **并发执行**，但是因为只回收一部分 `Region`，时间是用户可控制的，而且停顿 **用户线程** 将大幅提高回收效率。

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

> 与其它 `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`）。

### 内存分配与回收策略 ###

所谓自动内存管理，最终要解决的也就是内存分配和内存回收两个问题。前面我们介绍了内存回收，这里我们再来聊聊内存分配。

对象的内存分配通常是在 Java 堆上分配（随着虚拟机优化技术的诞生，某些场景下也会在栈上分配，后面会详细介绍），对象主要分配在新生代的 Eden 区，如果启动了本地线程缓冲，将按照线程优先在 TLAB 上分配。少数情况下也会直接在老年代上分配。总的来说分配规则不是百分百固定的，其细节取决于哪一种垃圾收集器组合以及虚拟机相关参数有关，但是虚拟机对于内存的分配还是会遵循以下几种「普世」规则：

#### 对象优先在 Eden 区分配 ####

多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存。

这里我们提到 Minor GC，如果你仔细观察过 GC 日常，通常我们还能从日志中发现 Major GC/Full GC。

*  **Minor GC** 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频繁，一般回收速度也非常快；
 *  **Major GC/Full GC** 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。

#### 大对象直接进入老年代 ####

所谓大对象是指需要大量连续内存空间的对象，频繁出现大对象是致命的，会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。

前面我们介绍过新生代使用的是标记-清除算法来处理垃圾回收的，如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。

#### 长期存活对象将进入老年代 ####

虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15） 就会被晋升到老年代。

#### 动态对象年龄判定 ####

为了更好的适应不同程序的内存情况，虚拟机并不是永远要求对象的年龄必需达到某个固定的值（比如前面说的 15）才会被晋升到老年代，而是会去动态的判断对象年龄。如果在 Survivor 区中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于等于该年龄的对象就可以直接进入老年代。

#### 空间分配担保 ####

在新生代触发 Minor GC 后，如果 Survivor 中任然有大量的对象存活就需要老年队来进行分配担保，让 Survivor 区中无法容纳的对象直接进入到老年代。

### 本章小结 ###

本章介绍了垃圾收集的算法，几款JDK1.7中提供的垃圾收集器特点以及运作原理。通过代码实例验证了Java虚拟机中自动内存分配及回收的主要规则。

内存回收与垃圾收集器在很多时候都是影响系统性能，并发能力的主要因素之一，虚拟机之所以提供多种不同的收集器以及提供大量的调节参数，是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最高的性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]: /images/20210920/a5af0805851448bc98c4f4e3f8ef980a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1]: /images/20210920/3405099fe0e64fd8bd1a4567aed47ade.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 2]: /images/20210920/a3582532494d4fd691129a99cb144dd8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 3]: /images/20210920/f43690035969499294cecfa02bdae6ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 4]: /images/20210920/f501c23341c041deabd65bda204560c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 5]: /images/20210920/747aab2484d0441aa8256d287a9ffa7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 6]: /images/20210920/6404ab12440c4d29a069376b95b789ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 7]: /images/20210920/fadd84b8972a4f89be2c553caf4fe910.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 8]: /images/20210920/37da58a6d6584d3db8a9fecec2553a4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 9]: /images/20210920/be075b6815784895a5b57c505ab6a9fd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 10]: /images/20210920/a99ce1e375f74b6d94f62c6b910953bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 11]: /images/20210920/56028f5155ac4d34b7f1b470b45b2751.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 12]: /images/20210920/948cff9c25a8459e85ac67bb8ddc2b24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 13]: /images/20210920/0c2bb9e8ce5b433aa2f1f73700936cbe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 14]: /images/20210920/24d30ffc988c4d35b2b5369bf1320157.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 15]: /images/20210920/f38d64f4797442eda9b80a3efd204e85.png