第 16 章一垃圾回收器、七种经典垃圾回收器、CMS回收器(重点)

àì夳堔傛蜴生んèń 2022-12-29 09:11 201阅读 0赞

# 第 16 章 垃圾回收器 #

## 1、GC 分类与性能指标 ##

### 1.1、垃圾回收器概述与分类 `(重点)` ###

> **垃圾回收器概述**

*  **垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。**
 *  由于JDK的版本处于高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。
 *  `从不同角度分析垃圾收集器，可以将GC分为不同的类型。`

**Java不同版本新特性**

1.  语法层面：Lambda表达式、switch、自动拆箱装箱、enum
2.  API层面：Stream API、新的日期时间、Optional、String、集合框架
3.  底层优化：JVM优化、GC的变化、元空间、静态域、字符串常量池位置变化

--------------------

**按线程数分（垃圾回收线程数），可以分为`串行垃圾回收器`和`并行垃圾回收器。`**

> 串行垃圾回收器和并行垃圾回收器的区别 :
> 
>  *  相同点: 都是`独占式`的, **用户线程**都**必须等**到**垃圾回收器**执行完才能执行, 造成了`Stop-the-World`
>  *  不同点:
>     
>      *  串行垃圾回收器 : 同一时间段只能`有一个cpu`执行垃圾回收
>      *  并行垃圾回收器 : 同一时间可以有`多个cpu`同时执行垃圾回收, 吞吐量提高了

1.  **`串行回收`** 指的是**在同一时间段内只允许有一个CPU用于执行垃圾回收操作**，此时**工作线程被暂停，直至垃圾收集工作结束。**
2.  和串行回收相反，**`并行收集`** 可以运用**多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，** 不过并行回收仍然与串行回收一样，采用`独占式`，使用了 **“Stop-the-World”** 机制。

![image-20200713083030867][]

**串行和并行垃圾回收器的适用场景**

1.  在诸如 **`单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合`**，`串行回收器的性能表现可以超过并行回收器和并发回收器`。所以，串行回收默认被应用在客户端的Client模式下的JVM中
2.  在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器

--------------------

**按照工作模式分，可以分为`并发式垃圾回收器`和`独占式垃圾回收器。(串行/并行垃圾回收器)`**

>  *  并**发垃圾回收器** : 可以和用户线程`交替执行`, 减少STW, 也就是减少用户线程的停顿时间。
>  *  **串行,并行回收器** : 就是`独占式`的垃圾回收器。用户线程必须要等到垃圾回收器执行完,才能恢复工作

1.  `并发式垃圾回收器`与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。
2.  `独占式垃圾回收器`（Stop the World）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。

![image-20200713083443486][]

--------------------

**按碎片处理方式分，可分为`压缩式垃圾回收器`和`非压缩式垃圾回收器。`**

>  *  压缩式垃圾回收器 : 将内存中的垃圾进行回收后, 对剩下的存活对象, `进行内存碎片整理`, 下次再来新对象的时候, 分配对象空间可用使用 `指针碰撞`。对内存碎片整理的垃圾回收算法 : `标记-压缩算法, 复制算法`
>  *  非压缩式垃圾回收器 : GC后, 对内存中存活的对象, 不会进行重新整理, 所以`内存出现碎片`, 此时如果再分配新对象, 分配方式用`空闲列表`, 不会对内存碎片整理的垃圾回收算法 : `标记-清除算法`

1.  压缩式垃圾回收器会在回收完成后，**对存活对象进行压缩整理，消除回收后的碎片**，分配对象空间使用 `指针碰撞`
2.  非压缩式的垃圾回收器**不对存活对象进行整理**，分配对象空间使用 `空闲列表`

--------------------

**按工作的内存区间分，又可分为`年轻代垃圾回收器`和`老年代垃圾回收器`。**

> 年轻代垃圾回收算法 : 一般使用`复制算法`, 在`幸存者`区就使用的是`复制算法`  
> 老年代垃圾回收算法 : 一般用`标记清除和标记压缩`算法

### 1.2、评估 GC 的性能指标 ###

> **评估 GC 的性能指标**

1.  **`吞吐量`：** **运行用户代码的时间占总运行时间的比例**（总运行时间 = 程序的运行时间 + 内存回收的时间）**`(越高越好)`**
2.  **`垃圾收集开销`：** 吞吐量的补数，**垃圾收集所用时间与总运行时间的比例。** **`(越低越好)`**
3.  **`暂停时间`：** 执行垃圾收集时，程序的工作线程被暂停的时间 (STW的时间)。**`(越低越好)`**
4.  `收集频率：`相对于应用程序的执行，GC收集操作发生的频率。
5.  `内存占用：`Java堆区所占的内存大小。
6.  快速：一个对象从诞生到被回收所经历的时间。

--------------------

**总结**

1.  **吞吐量、`暂停时间`、内存占用这三者共同构成一个“不可能三角”。** 三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。
2.  这三项里，**暂停时间的重要性日益凸显。** 因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟反而带来负面效果。
3.  简单来说，因为`内存不值钱了`，主要抓住两点：
    
     *  **`提高吞吐量`**
     *  **`减少用户线程的暂停时间 STW`**

> **评估 GC 的性能指标：吞吐量（throughput）**
> 
>  *  `吞吐量 = cpu执行用户代码执行时间 / cpu执行用户代码时间 + cpu执行垃圾收集的时间`
> 
> 就是用户线程执行的时间 占 总程序执行的时间 比例

1.  吞吐量 就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间 /（运行用户代码时间+垃圾收集时间）
2.  比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
3.  这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的
4.  **吞吐量优先，意味着在单位时间内，STW的时间最短：0.2+0.2=0.4**

*  下图`垃圾回收的频率只有两次`, **吞吐量就高了**  
    ![image-20200713084726176][]

> **评估 GC 的性能指标：暂停时间（pause time）**
> 
>  *  指当`垃圾回收线程`执行收集垃圾的时候, 此时`用户线程停下来 等待 垃圾收集器收集完垃圾 的时间`

1.  “暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态，例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的
2.  **暂停时间优先，意味着尽可能让单次STW的时间最短：0.1+0.1 + 0.1+ 0.1+ 0.1=0.5**

*  下图`提高了垃圾收集的次数`, 每次垃圾收集的时间很短, 如果再`并发垃圾回收器`下, cpu不断的进行上下文切换 (垃圾回收线程, 用户程序线程), 此时就会减少用户线程的STW, 给用户`低延迟`的感觉. 如此的话, `吞吐量就降低了`  
    ![image-20200713085306400][]

> **评估 GC 的性能指标：`吞吐量 vs 暂停时间`**
> 
>  *  **吞吐量和暂停时间 是一对竞争的目标(矛盾)**
>     
>      *  如果追求`高吞吐量`, 就必须降低`垃圾回收的频率`, 这样就会导致`当GC的时候, 垃圾收集时间长, 用户等待时间就长(STW长)`
>      *  如果追求`低延迟`, 也就是降低`垃圾回收时用户线程暂停的时间`, 此时就需要`频繁执行GC`, 频繁GC, 又导致了`吞吐量`的下降
>  *  **现在标准：`在最大吞吐量优先的情况下，降低停顿时间`**

1.  **`高吞吐量较好`** 因为这**会让应用程序的最终`用户感觉只有应用程序线程在做“生产性”工作`**。直觉上，吞吐量越高程序运行越快。
2.  **`低暂停时间（低延迟）较好`**，**因为从最终用户的角度来看，不管是`GC还是其他原因导致一个应用被挂起`始终是不好的。** 这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有较低的暂停时间是非常重要的，特别是对于一个交互式应用程序。
3.  不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标（矛盾）。
    
     *  因为如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。
     *  相反的，如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
4.  在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。
5.  **现在标准：`在最大吞吐量优先的情况下，降低停顿时间`**

## 2、不同的垃圾回收器概述 ##

> **不同的垃圾回收器概述**

1.  垃圾收集机制是Java的招牌能力，极大地提高了开发效率。这当然也是面试的热点。
2.  GC垃圾收集器是和JVM一脉相承的，它是和JVM进行搭配使用，在不同的使用场景对应的收集器也是有区别
3.  **那么，Java常见的垃圾收集器有哪些？**

### 2.1、垃圾收集器发展史 ###

> **垃圾收集器发展史**

有了虚拟机，就一定需要收集垃圾的机制，这就是Garbage Collection，对应的产品我们称为Garbage Collector。

1.  1999年随JDK1.3.1一起来的是`串行方式的Serial GC`，它是第一款GC。`ParNew垃圾收集器是Serial收集器的多线程版本`
2.  2002年2月26日，`Parallel GC`和`Concurrent Mark Sweep GC (CMS GC)`跟随JDK1.4.2一起发布·
3.  **Parallel GC在JDK6之后成为HotSpot默认GC。**
4.  2012年，在JDK1.7u4版本中，`G1`可用。
5.  2017年，**JDK9中`G1变成默认的垃圾收集器`，以替代CMS。**
6.  2018年3月，JDK10中G1垃圾回收器的并行完整垃圾回收，实现并行性来改善最坏情况下的延迟。
7.  2018年9月，JDK11发布。引入Epsilon 垃圾回收器，又被称为 "No-Op(无操作)“ 回收器。同时，引入`ZGC：可伸缩的低延迟垃圾回收器（Experimental）`
8.  2019年3月，JDK12发布。增强G1，自动返回未用堆内存给操作系统。同时，引入Shenandoah GC：低停顿时间的GC（Experimental）。
9.  2019年9月，JDK13发布。增强ZGC，自动返回未用堆内存给操作系统。
10. 2020年3月，JDK14发布。删除CMS垃圾回收器。扩展ZGC在macOS和Windows上的应用

### 2.2、7 种经典的垃圾收集器 `(重点)` ###

> **7种经典的垃圾收集器**

*  **`串行回收器：Serial (年轻代)、Serial old (老年代)`**
 *  **`并行回收器：ParNew (年轻代)、Parallel Scavenge (年轻代)、Parallel old (老年代)`**
 *  **`并发回收器：CMS (老年代)、G1 (年轻代/老年代)`** **(重点垃圾回收器)**

![image-20200713093551365][]

> **7款经典回收器与垃圾分代之间的关系**

*  **`新生代收集器：Serial、ParNew、Parallel Scavenge`**
 *  **`老年代收集器：Serial old、Parallel old、CMS`**
 *  **`整堆收集器：G1`**

![image-20200713093757644][]

### 2.3、垃圾收集器的组合关系 ###

> **垃圾收集器的组合关系**

1.  两个收集器间有连线，表明它们可以搭配使用：
    
     *  **`Serial/Serial old`**
     *  Serial/CMS (JDK8废弃、JDK9被移除)
     *  ParNew/Serial Old (JDK8废弃、JDK9被移除)
     *  **`ParNew/CMS`**
     *  Parallel Scavenge/Serial Old (JDK14中废弃)
     *  **`Parallel Scavenge / Parallel Old` (JDK8 默认GC)**
2.  **其中Serial Old作为CMS出现"Concurrent Mode Failure"失败的后备预案。(失败会进行Serial Old)**
3.  （红色虚线）由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、ParNew+Serial Old这两个组合声明为废弃（JEP173），并在JDK9中完全取消了这些组合的支持（JEP214），即：移除。
4.  （绿色虚线）**JDK14中：弃用Parallel Scavenge和Serial Old GC组合（JEP366）**
5.  （青色虚线）**JDK14中：删除CMS垃圾回收器（JEP363）**

![image-20200713094745366][]

**为什么需要那么多垃圾回收器?**

1.  为什么要有很多收集器，一个不够吗？**`因为Java的使用场景很多，移动端，服务器等。所以就需要针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。`**
2.  虽然我们会对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在，更加没有万能的收集器。**所以我们`选择的只是对具体应用最合适的收集器。`**

### 2.4、查看默认垃圾收集器 ###

> `JDK 8 中默认使用 ParallelGC 和 ParallelOldGC 的组合`

> **如何查看默认垃圾收集器**

1.  `-XX:+PrintCommandLineFlags`：查看命令行相关参数（包含使用的垃圾收集器）
2.  使用命令行指令：jinfo -flag 相关垃圾回收器参数 进程ID

--------------------

**设置 -XX:+PrintCommandLineFlags 查看**

*  在 JDK 8 下，设置 JVM 参数

-XX:+PrintCommandLineFlags

*  程序打印输出：`-XX:+UseParallelGC` 表示使用 ParallelGC ，**`ParallelGC 默认和 Parallel Old 绑定使用`**

-XX:InitialHeapSize=266620736 -XX:MaxHeapSize=4265931776 
    -XX:+PrintCommandLineFlags 
    -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation 
    -XX:+UseParallelGC

**通过命令行指令查看**

*  命令行命令

jps
    jinfo -flag UseParallelGC 进程id
    jinfo -flag UseParallelOldGC 进程id

*  JDK 8 中`默认使用 ParallelGC 和 ParallelOldGC` 的组合

![image-20200802145133680][]

## 3、Serial 回收器：串行回收器 ##

### 3.1、Serial 回收器 ###

> **Serial 回收器：串行回收**
> 
>  *  Servial回收器(收集年轻代) : 该回收器使用的是 `复制算法`, 因为是串行回收器, 所以当`垃圾回收的时候`, 会产生`STW`。
>  *  Servial Old回收器 (收集老年代) : 它使用的是 `标记-压缩算法`, 其他同上

1.  Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
2.  **Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。**
3.  Serial收集器采用`复制算法`、串行回收和"Stop-the-World"机制的方式执行内存回收。
4.  除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。**Serial old收集器同样也采用了串行回收和"Stop the World"机制，只不过内存回收算法使用的是`标记-压缩`算法。**
5.  **`Serial Old GC是运行在Client模式下默认的老年代的垃圾回收器，Serial Old在Server模式下主要有两个用途：`**
    
     *  `与新生代的Parallel Scavenge配合使用`
     *  `作为老年代CMS收集器的后备垃圾收集方案`

> **Serial 回收器举例**

这个收集器是一个单线程的收集器，“单线程”的意义：(串行)

1.  它只会使用一个CPU或一条收集线程去完成垃圾收集工作
2.  更重要的是在**它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（Stop The World）**

![image-20200713100703799][]

### 3.2、Serial 回收器的优势 ###

> **Serial 回收器的优势**
> 
>  *  **单线程情况下, `简单高效`, 不需要多线程之间的交互, 没有`上下文切换`带来的性能开销**

1.  优势：**`简单而高效（与其他收集器的单线程比）`，对于限定单个CPU的环境来说，Serial收集器由于`没有线程交互的开销`，专心做垃圾收集自然可以获得最高的单线程收集效率。**
2.  运行在Client模式下的虚拟机是个不错的选择。
3.  在用户的桌面应用场景中，可用内存一般不大（几十MB至一两百MB），可以在较短时间内完成垃圾收集（几十ms至一百多ms），只要不频繁发生，使用串行回收器是可以接受的。

### 3.3、设置 Serial 垃圾回收器 ###

> **设置 Serial 垃圾回收器**
> 
>  *  `-XX:+UseSerialGC` : 指定`年轻代和老年代`都使用串行收集器
>  *  等价于新生代用Serial GC，且老年代用Serial Old GC

1.  在HotSpot虚拟机中，使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。
2.  等价于新生代用Serial GC，且老年代用Serial Old GC

> **Serial 回收器总结**
> 
>  *  因为是串行, 所以不使用 !

1.  这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核CPU才可以用。现在都不是单核的了。
2.  对于交互较强的应用而言，这种垃圾收集器是不能接受的。一般在Java Web应用程序中是不会采用串行垃圾收集器的。

## 4、PaeNew 回收器：并行回收 (新生代) ##

### 4.1、PaeNew 回收器 ###

> **ParNew 回收器：并行回收**
> 
>  *  `ParNew (收集年轻代)` : ParNew收集器则是Serial收集器的多线程版本。也是采用`复制算法`, 存在`STW`

1.  如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本。
2.  Par是Parallel的缩写，New：只能处理新生代
3.  ParNew 收集器除了采用`并行回收`的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。**ParNew收集器在年轻代中同样也是采用复制算法、"Stop-the-World"机制。**
4.  ParNew 是很多JVM运行在Server模式下新生代的默认垃圾收集器。

![image-20200713102030127][]

> **并行 Or 串行**

1.  **对于`新生代`，回收次数频繁，使用`并行方式高效`。**
2.  **对于`老年代`，回收次数少，使用`串行方式节省资源`。**（CPU并行需要切换线程，串行可以省去切换线程的资源）

### 4.2、ParNew 与 Serial 比较 ###

> **ParNew 回收器与 Serial 回收器效率比较**
> 
>  *  ParNew 是采用`并行回收方式`, Serial才用`串行回收方式`
>  *  在多核CPU环境下, ParNew并行回收垃圾, 可以充分利用多CPU, 效率高提高`吞吐量`
>  *  在单核CPU环境下, Serial没有`上下文切换`带来的性能开销, 此时Servial效率更高

由于ParNew收集器基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效？并不能

1.  **`ParNew收集器`运行在多CPU的环境下**，由于**可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，`提升程序的吞吐量`。**
2.  但是在**单个CPU的环境下**，**ParNew收集器不比Serial收集器更高效。虽然Serial收集器是基于串行回收，但是`由于CPU不需要频繁地做任务切换`**，因此可以有效避免多线程交互过程中产生的一些额外开销。

### 4.3、设置 ParNew 垃圾回收器 ###

> **设置 ParNew 垃圾回收器**
> 
>  *  `-XX:+UseParNewGC`

1.  在程序中，开发人员可以通过选项"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。
2.  \-XX:ParallelGCThreads限制线程数量，默认开启和CPU数据相同的线程数。

## 5、Parallel 回收器：吞吐量优先 (`JDK8默认垃圾回收器`) ##

### 5.1、Parallel 回收器 ###

> **Parallel Scavenge (年轻代)回收器：吞吐量优先**
> 
>  *  也是并行的垃圾回收器, 同样采用`复制算法`
>  *  **Parallel Old(老年代)回收器：吞吐量优先**
>     
>      *  Parallel Old收集器采用了`标记-压缩算法`，但同样也是基于并行回收和"Stop-the-World"机制。

1.  **HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，`Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World"机制。`**
2.  那么Parallel收集器的出现是否多此一举？
    
     *  **和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput），它也被称为`吞吐量优先的垃圾收集器。`**
     *  **`自适应调节策略`也是`Parallel Scavenge`与`ParNew`一个重要区别。**
3.  高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
4.  `Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器，用来代替老年代的Serial Old收集器。`
5.  Parallel Old收集器采用了标记-压缩算法，但同样也是基于并行回收和"Stop-the-World"机制。

![image-20200713110359441][]

1.  在程序吞吐量优先的应用场景中，**Parallel收集器和Parallel Old收集器的组合，在server模式下的内存回收性能很不错。**
2.  **`在Java8中，默认是此垃圾收集器。`**

### 5.2、Parallel 回收器参数设置 ###

> **Parallel Scavenge 回收器参数设置**

1.  `-XX:+UseParallelGC` : 手动指定年轻代使用Parallel并行收集器执行内存回收任务。
2.  `-XX:+UseParallelOldGC`：手动指定老年代都是使用并行回收收集器。
3.  上面两个参数分别适用于新生代和老年代。默认jdk8是开启的。**默认开启一个，另一个也会被开启。（互相激活）**

--------------------

*  **`-XX:ParallelGCThreads：设置年轻代并行收集器的线程数。`** 一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。

1.  在默认情况下，当CPU数量小于8个，ParallelGCThreads的值等于CPU数量。
2.  当CPU数量大于8个，ParallelGCThreads的值等于3+\[5\*CPU\_Count\]/8\]

--------------------

*  **`-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即STW的时间）。单位是毫秒。`**

1.  为了尽可能地把停顿时间控制在XX:MaxGCPauseMillis 以内，收集器在工作时会调整Java堆大小或者其他一些参数。
2.  对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。该参数使用需谨慎。

--------------------

*  `-XX:GCTimeRatio`垃圾收集时间占总时间的比例，即等于 1 / (N+1) ，**`用于衡量吞吐量的大小。`**

1.  取值范围(0, 100)。默认值99，也就是垃圾回收时间占比不超过1。
2.  与前一个-XX:MaxGCPauseMillis参数有一定矛盾性
3.  STW暂停时间越长，Radio参数就容易超过设定的比例。

--------------------

*  `-XX:+UseAdaptiveSizePolicy` 设置Parallel Scavenge收集器具有 **`自适应调节策略`**

1.  **在这种模式下，`年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。`**
2.  在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMillis），让虚拟机自己完成调优工作。

### **总结: 上面五种垃圾回收器:** (`重点`) ###

> **Serial 回收器：串行回收器**
> 
>  *  ① **Servial 回收器(收集年轻代)** : 该回收器使用的是 `复制算法`, 因为是串行回收器, 所以当`垃圾回收的时候`, 会产生`STW`。
>  *  ② **Servial Old 回收器 (收集老年代)** : 它使用的是 `标记-压缩算法`, 其他同上
>  *  **优势 :** 单线程情况下, `简单高效`, 不需要多线程之间的交互, 没有`上下文切换`带来的性能开销

> ③ **ParNew 回收器：并行回收**
> 
>  *  `ParNew (收集年轻代)` : ParNew收集器则是Serial收集器的多线程版本。也是采用`复制算法`, 存在`STW`

> **Parallel 并行回收器 : 吞吐量优先 (JDK8默认垃圾回收器)**
> 
>  *  ④ **Parallel Scavenge (年轻代)回收器：吞吐量优先**
>     
>      *  也是并行的垃圾回收器, 同样采用`复制算法`
>  *  ⑤ **Parallel Old(老年代)回收器：吞吐量优先**
>     
>      *  Parallel Old收集器采用了`标记-压缩算法`，但同样也是基于并行回收和"Stop-the-World"机制。

> **Parallel 回收器与 ParNew 回收器比较**
> 
>  *  两者都是并行回收器
>  *  和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个`可控制的吞吐量（Throughput）`，它也被称为吞吐量优先的垃圾收集器。
>  *  `自适应调节策略`也是Parallel Scavenge与ParNew一个重要区别。
>     
>      *  可以设置垃圾收集器最大停顿时间
>      *  **可以自适应调整** 年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。

--------------------

## 6、CMS (并发标记清除) 回收器：低延迟 (并发回收) (`重重点`) ##

### 6.1、CMS 回收器 (第一款并发收集器) ###

> **CMS 回收器：低延迟** (收集老年代)
> 
>  *  并发垃圾收集器, 实现了`垃圾回收线程`和`用户线程`同时工作
>  *  采用`标记-清除`算法, 也会有`STW`
>  *  `CMS(并发收集老年代)`无法和JDK8的`Parallel Scavenge(并行收集年轻代,要求吞吐量)`无法配合工作; 只能和串行收集的Serial 和 并行收集的ParNew配合使用

1.  在JDK1.5时期，Hotspot推出了一款在强交互应用中几乎可认为有**划时代意义的垃圾收集器：CMS（Concurrent-Mark-Sweep）收集器**，这款收集器是HotSpot虚拟机中`第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。`
2.  CMS收集器的关注点是 **尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。**
3.  目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
4.  CMS的垃圾收集算法采用标记-清除算法，并且也会"Stop-the-World"
5.  不幸的是，CMS作为老年代的收集器，却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
6.  **在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC。**

### 6.2、CMS 工作原理 (`必背重点`) ###

> **CMS 工作原理**

CMS整个过程比之前的收集器要复杂，整个过程分为 **`4`** 个主要阶段，即 **`初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段`。** (涉及STW的阶段主要是：初始标记 和 重新标记)

*  `初始标记（Initial-Mark）阶段`：*在这个阶段中，程序中所有的工作线程都将会因为“Stop-the-World”机制而出现短暂的暂停*，**`这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象`**。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的速度非常快。
 *  `并发标记（Concurrent-Mark）阶段`：**`从GC Roots的直接关联对象开始遍历整个对象图的过程`**，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
 *  `重新标记（Remark）阶段`：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此 **`为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录`(因为并发标记和用户线程同时执行,可能导致已经标记的可达对象, 在用户执行过程中改变为不可达, 所以需要重新标记阶段)** ，这个阶段的停顿时间通常会比初始标记阶段稍长一些，并且也会导致“Stop-the-World”的发生，但也远比并发标记阶段的时间短。
 *  `并发清除（Concurrent-Sweep）阶段`：**`此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间`**。由于不需要移动存活对象`(因为是标记清除算法)`，所以这个阶段也是可以与用户线程同时并发的

![image-20200713205154007][]

### 6.3、CMS 特点与弊端分析 ###

> **CMS 特点与弊端分析**
> 
>  *  CMS是并发回收, 但是`初始化标记、重新标记`两个阶段还是需要执行`STW`, CMS尽可能低延迟, 确保用户的体验
>  *  因为`垃圾回收`过程中, `用户线程`仍然在执行, 我们要确保应用程序有足够的`内存`, 此时会出现一次`Concurrent Mode Failure (并发故障)`, 启动虚拟机后备方案; 临时启用`Serial Old`收集器来对老年代重新回收, 这样STW时间就更长了
>  *  CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是`当堆内存使用率达到某一阈值时，便开始进行回收`，以\`确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。
>  *  由于使用的是`标记-清除`算法, 所以会产生`内存碎片`, 当再为对象分配内存的时候, 只能采用`空闲列表`的方式, 无法使用`指针碰撞`的分配方式

> **为什么 CMS 不采用标记-压缩算法呢 ?**
> 
>  *  因为当`并发清除`的时候，用`标记压缩整理内存`的话，原来的用户线程正在使用的`内存`, 没办法通过移动`存活对象的地址`, 因为正在使用这些对象, 地址无法被改变。
>  *  要保证用户线程能继续执行，**前提的它运行的资源不受影响**。`标记压缩`更适合`“stop the world”`这种场景下使用; (因为STW的时候, 用户线程就不运行了,此时可以整理存活对象的内存, 解决内存碎片问题)

1.  **尽管CMS收集器采用的是`并发回收（非独占式）`，但是在其`初始化标记`和`再次标记`这两个阶段中仍然需要执行`“Stop-the-World”机制`暂停程序中的工作线程**，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要“Stop-the-World”，只是尽可能地缩短暂停时间。
2.  由于*最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的*。另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该 **`确保应用程序用户线程有足够的内存可用。`**
3.  因此，**CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是`当堆内存使用率达到某一阈值时，便开始进行回收`，以`确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。`**
4.  要是CMS运行期间预留的**内存无法满足**程序需要，就会出现一次 **“Concurrent Mode Failure”** 失败，**这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。**
5.  CMS收集器的垃圾收集算法采用的是 **`标记清除算法`**，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，**不可避免地将会产生一些内存碎片**。那么CMS在为新对象分配内存空间时，**将`无法使用指针碰撞（Bump the Pointer）技术`，而`只能够选择空闲列表（Free List）执行内存分配。`**  
    ![image-20200713212230352][]

### 6.4、CMS 的优点与缺点 ###

> **CMS 的优点与缺点**

**优点**

*  **`并发收集`**
 *  **`低延迟`**

**缺点**

1.  `会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。`
2.  CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
3.  **CMS收集器无法处理浮动垃圾。(并发标记阶段产生的新垃圾)** 可能出现“Concurrent Mode Failure"失败而导致另一次Full GC的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

### 6.5、CMS 参数配置 ###

> **CMS 参数配置**

*  `-XX:+UseConcMarkSweepGC`：手动指定使用CMS收集器执行内存回收任务。
 *  开启该参数后会自动将`-XX:+UseParNewGC打开`。即：**ParNew（Young区）+CMS（Old区）+Serial Old（Old区备选方案）的组合。**

--------------------

*  `-XX:CMSInitiatingOccupanyFraction`：设置堆内存使用率的`阈值 (堆空间45%)`，一旦达到该阈值，便开始进行回收。

1.  JDK5及以前版本的默认值为68，即当老年代的空间使用率达到68%时，会执行一次CMS回收。JDK6及以上版本默认值为92%
2.  如果**内存增长缓慢，则可以设置一个稍大的值**，大的阀值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。
3.  反之，**如果应用程序内存使用率增长很快，则应该降低这个阈值，** 以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数。

--------------------

*  `-XX:+UseCMSCompactAtFullCollection`：用于`指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。`不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。

--------------------

*  `-XX:CMSFullGCsBeforeCompaction`：设置在执行多少次Full GC后对内存空间进行压缩整理。

--------------------

*  `-XX:ParallelCMSThreads`：**设置CMS的线程数量。**

1.  **CMS默认启动的线程数是`(ParallelGCThreads + 3) / 4`**，**ParallelGCThreads是年轻代并行收集器的线程数，可以当做是 CPU 最大支持的线程数**
2.  当CPU资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。

### 6.6、如何选择垃圾回收器 (`重点`) ###

> **如何选择垃圾回收器？**

HotSpot有这么多的垃圾回收器，那么如果有人问，Serial GC、Parallel GC、Concurrent Mark Sweep GC这三个GC有什么不同呢？

1.  如果你想要最小化地使用内存和并行开销，**请选Serial GC；(减少上下文切换)**
2.  如果你想要最大化应用程序的吞吐量，**请选Parallel GC；(最大化吞吐量)**
3.  如果你想要最小化GC的中断或停顿时间，**请选CMS GC。(减少STW, 增高低延迟)**

> **JDK 后续版本中 CMS 的变化**

1.  **JDK9新特性：CMS被标记为Deprecate(弃用)了（JEP291）**
    
     *  如果对JDK9及以上版本的HotSpot虚拟机使用参数-XX:+UseConcMarkSweepGC来开启CMS收集器的话，用户会收到一个警告信息，提示CMS未来将会被废弃。
2.  **JDK14新特性：删除CMS垃圾回收器（JEP363）移除了CMS垃圾收集器，**
    
     *  如果在JDK14中使用XX:+UseConcMarkSweepGC的话，JVM不会报错，只是给出一个warning信息，但是不会exit。`JVM会自动回退以默认GC方式启动JVM`

[image-20200713083030867]: /images/20221120/5f4f43d169a94933821b2a2c9d849b08.png
[image-20200713083443486]: /images/20221120/1c23aab0310f4fc3a06398df7fa2ad4b.png
[image-20200713084726176]: /images/20221120/8e882e2169fe4007ab0017fb896e4dd0.png
[image-20200713085306400]: /images/20221120/5abb5c0afe03452883e73af59649862d.png
[image-20200713093551365]: /images/20221120/bd6b58eea1be4ee6b73eda734e6ba85f.png
[image-20200713093757644]: /images/20221120/6555d8d20ff84b368bfaa6b784c5cd32.png
[image-20200713094745366]: /images/20221120/7b87dff5df4d4b5a98abcf9b8f142ba8.png
[image-20200802145133680]: /images/20221120/062bf771d27f4c5b98793a40630eca08.png
[image-20200713100703799]: /images/20221120/e9676407db8d404097d79d466ded4c17.png
[image-20200713102030127]: /images/20221120/9bd9006a3e0e4e3799b161a60045775e.png
[image-20200713110359441]: /images/20221120/121bca2d3d8347e49880a257d99eb8c0.png
[image-20200713205154007]: /images/20221120/e02ed05dd2dd4417a0d6e9a232002005.png
[image-20200713212230352]: /images/20221120/eee1621c8428430385d3c0a560d7df95.png