第 17 章一 G1回收器(重点)、垃圾回收器总结(重要)、GC日志分析、垃圾回收器的新发展(了解)

骑猪看日落 2023-01-08 03:29 266阅读 0赞

> 由于篇幅, 无缝衔接上篇博客 !

## 7、G1 回收器 (`重重点`)：`区域化分代式` (并行回收器) JDK9的默认垃圾回收器 ##

### 7.1、为什么还需要 G1 ###

> **`在延迟可控的情况下, 尽可能获取高的吞吐量`**
> 
>  *  采用`标记-压缩`算法

> **既然我们已经有了前面几个强大的 GC ，为什么还要发布 Garbage First（G1）GC？**

1.  GC一直优化的原因就在于 **`应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。`**
2.  G1（Garbage-First）垃圾回收器是在Java7 update4之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一。
3.  与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。
4.  官方给 **`G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐`，所以才担当起“全功能收集器”的重任与期望。**

### 7.2、G1 的含义 (region分区) ###

> **为什么名字叫 Garbage First(G1) 呢？**
> 
>  *  并行回收器, 避免对整个`堆空间`进行垃圾回收, 将`堆空间`分割为很多不相关的区域(`Region`)
>     
>      *  **不同的Region来表示`Eden`、`幸存者0区`，`幸存者1区`，`老年代`等**
>  *  每次回收不同的Region, 后台维护一个有限列表, G1跟踪每个Region垃圾堆积的大小, 从而优先选择`回收价值最大(不可达对象多的)`的Region, 所以我们给G1一个名**字：垃圾优先（Garbage First）。**

1.  **因为G1是一个`并行回收器`，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的）。`使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。`**
2.  G1 GC有计划地 **避免在整个Java堆中进行全区域的垃圾收集。** G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个`优先列表`，每次根据允许的收集时间，`优先回收价值最大的Region。`
3.  由于这种方式的`侧重点在于回收垃圾最大量的区间（Region）`，所以我们给G1一个名字：**垃圾优先（Garbage First）。**
4.  G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，**以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。**
5.  在JDK1.7版本正式启用，移除了Experimental的标识，**`是JDK9以后的默认垃圾回收器，取代了CMS回收器以及Parallel+Parallel Old组合。被Oracle官方称为“全功能的垃圾收集器”。`**
6.  与此同时，CMS已经在JDK9中被标记为废弃（deprecated）。**G1 在JDK8中还不是默认的垃圾回收器，需要使用`-XX:+UseG1GC`来启用。**

### 7.3、G1 回收器的优点 ###

> 同时可以回收`老年代`, `年轻代`

> **G1 回收器的特点（优势）**
> 
>  *  **并行性**: 可以用多个GC线程同时进行垃圾回收, 减少用户STW, 充分利用CPU多核
>  *  **并发性**: GC的时候, `垃圾回收线程`可以和 `用户线程`交替执行
>  *  **分区回收**: 同时可以回收`年轻代,老年代`

与其他GC收集器相比，`G1使用了全新的分区算法`，其特点如下所示：

1.  **并行与并发兼具**
    
     *  并行性：**G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时减少用户线程STW**
     *  并发性：**G1拥有与应用程序交替执行的能力**，部分工作可以和应用程序同时执行，因此，一般来说，`不会在整个回收阶段发生完全阻塞应用程序的情况`
2.  **分代收集**
    
     *  从分代上看，G1依然属于`分代型垃圾回收器`，**它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。**
     *  将堆空间分为若干个区域（Region），这些区域中包含了逻辑上的年轻代和老年代。
     *  和之前的各类回收器不同，**它同时兼顾年轻代和老年代。** 对比其他回收器，或者工作在年轻代，或者工作在老年代；

### 7.4、G1 回收器的分区 ###

> **G1 回收器的分区**

G1的分代，已经不是下面这样的了

![image-20200713215105293][]

G1的分区是这样的一个区域

![image-20200713215133839][]

### 7.5、G1 的空间整合 ###

> **G1 的空间整合**

**空间整合**

1.  CMS：`“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理`
2.  G1将内存划分为一个个的`region`。内存的回收是以region作为基本单位的。**Region之间是`复制算法`(幸存者0, 幸存者1)**，但整体上实际可看作是`标记-压缩（Mark-Compact）`算法，两种算法都`可以避免内存碎片`。
3.  这种特性有利于程序长时间运行，**`分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。(因为使用了`标记压缩算法`, 会整理内存碎片, 可以存储大的对象)`**
4.  `CMS`采用的是`标记-清除算法`, 会导致`内存碎片`。

### 7.6、可预测的停顿时间模型 `(手动控制垃圾回收的时间)` (`重点`) ###

> **可预测的停顿时间模型（即：软实时soft real-time）**
> 
>  *  `指定一个毫秒的时间片呢, 垃圾回收的消耗时间,不能超过这个时间。`
>     
>      *  `-XX:MaxGCPauseMillis`：设置期望达到的最大GC停顿时间指标, JVM尽可能达到该停顿指标

**这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。**

1.  由于分区的原因，G1可以只选取`部分区域(回收价值高的区域)`进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。
2.  `G1跟踪各个Region里面的垃圾堆积的价值大小`（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个**优先列表**，每次根据允许的收集时间，**优先回收价值最大的Region**。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
3.  相比于CMS GC，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。

### 7.7、G1 回收器的缺点 (小应用CMS强, 大应用G1强) ###

> **G1 回收器的缺点**

1.  相较于CMS，**G1还不具备全方位、压倒性优势。** 比如在用户程序运行过程中，**G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。**
2.  **从经验上来说，`在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。`**

### 7.8、G1 参数配置 ###

> **G1 参数配置**

*  **`-XX:+UseG1GC`**：手动指定`使用G1垃圾收集器`执行内存回收任务

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

*  `-XX:G1HeapRegionSize`：设置每个Region的大小。
 *  值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。**默认是堆内存的1/2000。**

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

*  **`-XX:MaxGCPauseMillis`**：设置期望达到的最大GC停顿时间指标
 *  JVM会尽力实现，但不保证达到。默认值是200ms

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

*  **`-XX:+ParallelGCThread`**：设置STW工作线程数的值。最多设置为8

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

*  `-XX:ConcGCThreads`：设置并发标记的线程数。
 *  将n设置为并行垃圾回收线程数（ParallelGcThreads）的1/4左右。

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

*  `-XX:InitiatingHeapOccupancyPercent`：设置**触发并发GC周期的Java堆占用率阈值**。
 *  超过此值，就触发GC。默认值是**45**。

> **G1 收集器的常见操作步骤**

G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

*  第一步：`开启G1垃圾收集器`
 *  第二步：`设置堆的最大内存`
 *  第三步：`设置最大的停顿时间` (JVM尽可能满足)

**G1中提供了`三种垃圾回收模式`**：Y**oungGC、Mixed GC和Full GC，在不同的条件下被触发。**

### 7.9、G1的适用场景 ###

> **G1收集器的适用场景**
> 
>  *  **`面向服务端, 大内存,大应用, 多处理器的机器`**
>  *  **需要应用程序`低延迟`, 并且堆空间足够大的应用程序**

*  面向服务端应用，针对具有大内存、多处理器的机器。（在普通大小的堆里表现并不惊喜）
 *  **最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案；**
    
     *  如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；（G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长）。
 *  用来替换掉JDK1.5中的CMS收集器；在下面的情况时，使用G1可能比CMS好：
    
     *  超过50%的Java堆被活动数据占用；
     *  对象分配频率或年代提升频率变化很大；
     *  GC停顿时间过长（长于0.5至1秒）
 *  HotSpot垃圾收集器里
    
     *  除了G1以外，**其他的垃圾收集器均使用`内置的JVM线程`执行GC的多线程操作**
     *  **而G1 GC可以采用`应用线程`承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。**

### 7.10、分区 Region (将堆分为2048个Region) ###

> **分区 Region：化整为零**
> 
>  *  将堆分为`2048`个Region块, 大小相同. Region有`Eden`, `Survivor`, `Old`等区域, 还有`H区`, 用来存放大对象, **该对象超过一个Eden分区的二分之一, 就会放到H区**

1.  使用`G1收集器时`，它将`整个Java堆`划分成约`2048个大小相同的独立Region块`，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB，8MB，16MB，32MB。可以通过
2.  `-XX:G1HeapRegionSize`设定Region大小。**所有的Region大小相同**，且在JVM生命周期内不会被改变。
3.  **虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。** 通过Region的动态分配方式实现逻辑上的连续。
4.  `一个Region有可能属于Eden，Survivor或者Old/Tenured内存区域`。但是一个Region只可能属于一个角色。图中的E表示该Region属于Eden内存区域，S表示属于Survivor内存区域，O表示属于Old内存区域。图中空白的表示未使用的内存空间。
5.  **G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。`主要用于存储大对象，如果超过0.5个Region，就放到H。`**

![image-20200713223244886][]

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

**设置 H 的原因**

1.  **`对于堆中的大对象，默认直接会被分配到老年代(老年代回收频率低)，但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。`**
2.  **为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。**
3.  如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待。

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

**Regio的内部结构**

> 通过`指针碰撞`来分配空间

1.  每个Region都是通过`指针碰撞`来分配空间
2.  每个Region都有`TLAB`，提高对象分配的效率

![image-20200713223509993][]

### 7.11、G1垃圾回收器- 垃圾回收流程 ###

> **G1 回收器垃圾的主要环节**

G1 GC的垃圾回收过程主要包括如下三个环节：

*  `年轻代GC（Young GC）`
 *  `老年代并发标记过程（Concurrent Marking）`
 *  `混合回收（Mixed GC）`
 *  （如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。）

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

顺时针，`Young GC --> Young GC+Concurrent Marking --> Mixed GC顺序，进行垃圾回收`

![image-20200713224113996][]  
**大致的回收流程 (上图)**

>  *  **年轻代回收**: 回收时是`并行`,独占式的收集, 收集期间, 用户线程STW, 将`存活对象`移动到`Survivor或者Old`区
>  *  当堆内存使用率达到`45%`, 开始 **并发标记老年代(标记老年代的可达对象)**, 标记完成就进行`混合回收`
>  *  **混合回收**: **将年轻代和老年代的回收价值高的Region一起回收**, G1 GC从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。

*  举个例子：一个Web服务器，Java进程最大堆内存为4G，每分钟响应1500个请求，每45秒钟会新分配大约2G的内存。G1会每45秒钟进行一次年轻代回收，每31个小时整个堆的使用率会达到45%，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收。

> **G1 回收器垃圾回收过程：`Remembered Set（记忆集）`**

**存在的问题**

1.  **`一个对象被不同区域(Region)引用的问题`**
2.  **一个Region不可能是孤立的，`一个Region中的对象可能被其他任意Region中对象引用`，判断对象存活时，是否需要扫描整个Java堆才能保证准确？**
3.  在其他的分代收集器，也存在这样的问题（而G1更突出，因为G1主要针对大堆, 如果通过扫描整个堆来判断, 代价太大）
    
     *  **回收新生代也不得不同时扫描老年代？这样的话会降低Minor GC的效率**

**解决方法：**

> 解决不同`Region`的引用问题, 可以给每一个`Region`设置一个`Rememberd Set`记忆集,
> 
>  *  当进行比较GCRoot中的可达对象时, 枚举到每一个Region的Remembered Set, 这样就不用进行去全局扫描,也不会有遗漏的可达对象。

1.  无论G1还是其他分代收集器，`JVM都是使用Remembered Set来避免全局扫描；`
2.  **每个Region都有一个对应的`Remembered Set`**
3.  每次Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作；
4.  然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region（其他收集器：检查老年代对象是否引用了新生代对象）；
5.  如果不同，通过`CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中；`
6.  **当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set；就可以保证不进行全局扫描，也不会有遗漏。**

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

解决不同Region引用的问题 :

1.  `在回收 Region 时，为了不进行全堆的扫描，引入了 Remembered Set`
2.  `Remembered Set 记录了当前 Region 中的对象被哪个对象引用了`
3.  `这样在进行 Region 复制时，就不要扫描整个堆，只需要去 Remembered Set 里面找到引用了当前 Region 的对象`
4.  `Region 复制完毕后，修改 Remembered Set 中对象的引用即可`

![image-20200713224716715][]

### 7.12、G1 年轻代 GC ###

> **G1 回收过程：年轻代 GC (此过程是一个独占式的, 用户线程要停止)**

1.  JVM启动时，G1先准备好Eden区，程序在运行过程中不断创建对象到Eden区，`当Eden空间耗尽时，G1会启动一次年轻代垃圾回收过程。`
2.  **YGC时，首先`G1停止应用程序的执行`（Stop-The-World），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，`年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。`**

![image-20200713225100632][]

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

**G1回收年轻代的过程：**

1.  第一阶段，**扫描GCRoot寻找可达对象**
    
     *  根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。
     *  `根据扫描到的可达对象, 以及关联的RSet的外部对象都作为 可达对象`。
2.  第二阶段，**更新RSet**
    
     *  处理dirty card queue（见备注）中的card，更新RSet。
     *  此阶段完成后，`RSet可以准确的反映老年代对所在的内存分段中对象的引用。`
3.  第三阶段，**处理RSet**
    
     *  识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象。
4.  第四阶段，**复制对象。(Eden中的对象复制到Survivor中)**
    
     *  此阶段，对象树被遍历，`Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，Survivor区内存段中存活的对象`
     *  `如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到Old区中空的内存分段。`
     *  `如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。`
5.  第五阶段，**处理引用**
    
     *  `处理Soft，Weak，Phantom，Final，JNI Weak 等引用`。最终Eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。

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

**备注：** 增加对象引用, 通过`Region的记忆集`

1.  对于应用程序的引用赋值语句 **oldObject.field=new Object()，JVM会在之前和之后执行特殊的操作以在`dirty card queue`中入队一个保存了对象引用信息的card (卡表)。**
2.  **在年轻代回收的时候，G1会对Dirty Card Queue中所有的card进行处理，以更新RSet，保证RSet实时准确的反映引用关系。**
3.  那为什么不在引用赋值语句处直接更新RSet呢？这是**为了性能的需要，RSet的处理需要线程同步，开销会很大，使用队列性能会好很多。**

### 7.13、G1 并发标记过程 (和CMS流程类似) ###

> **G1 回收过程：并发标记过程**

1.  **初始标记阶段：**
    
     *  **`标记从根节点直接可达的对象。这个阶段是STW的，并且会触发一次年轻代GC。`**
     *  正是由于该阶段时STW的，所以我们只扫描根节点可达的对象，以节省时间。
2.  **根区域扫描（Root Region Scanning）：**
    
     *  `G1 GC扫描Survivor区直接可达的老年代区域对象，并标记被引用的对象。`
     *  这一过程必须在Young GC之前完成，因为Young GC会使用复制算法对Survivor区进行GC。
3.  **并发标记（Concurrent Marking）：**
    
    1.  在整个堆中进行并发标记（和应用程序并发执行），此过程可能被Young GC中断。
    2.  在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。
    3.  **同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）。(为了选择性回收Region)**
4.  **再次标记（Remark）：**
    
     *  `由于应用程序持续进行，需要修正上一次的标记结果`。是STW的。
     *  G1中采用了比CMS更快的初始快照算法：Snapshot-At-The-Beginning（SATB）。
5.  **独占清理（cleanup，STW）：**
    
     *  **计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。**
     *  为下阶段做铺垫。是STW的。这个阶段并不会实际上去做垃圾的收集
6.  **并发清理阶段：**
    
     *  **识别并清理完全空闲的区域。**

### 7.14、G1 混合回收过程 ###

> **G1 回收过程：混合回收**

1.  **当越来越多的对象晋升到老年代Old Region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，** `该算法并不是一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region。`
2.  这里需要注意：是`一部分老年代`，而不是全部老年代。可以选择哪些Old Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是`Mixed GC`并不是Full GC。

![image-20200713225810871][]

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

**混合回收的细节** (了解)

1.  并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。
2.  默认情况下，这些老年代的内存分段会分8次（可以通过-XX:G1MixedGCCountTarget设置）被回收
3.  混合回收的回收集（Collection Set）包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
4.  由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收。
5.  XX:G1MixedGCLiveThresholdPercent，默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。
6.  混合回收并不一定要进行8次。有一个阈值-XX:G1HeapWastePercent，默认值为10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。

### 7.15、G1 的注意事项 ###

> **G1 回收可选的过程四：Full GC**

1.  `G1的初衷`就是要`避免Full GC`的出现。但是如果上述方式不能正常工作，G1会停止应用程序的执行（Stop-The-World），使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。
2.  要避免Full GC的发生，一旦发生Full GC，需要对JVM参数进行调整。什么时候会发生Ful1GC呢？比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到Full GC，这种情况可以通过增大内存解决。

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

导致G1 Full GC的原因可能有两个：

1.  Evacuation(回收阶段)的时候**没有足够的to-space来存放晋升的对象；**
2.  `并发处理过程完成之前空间耗尽。`

> **G1 回收器的补充 (看看即可)**

1.  从Oracle官方透露出来的信息可获知，回收阶段（Evacuation）其实本也有想过设计成与用户程序一起并发执行，但这件事情做起来比较复杂，考虑到G1只是回一部分Region，停顿时间是用户可控制的，所以并不迫切去实现，而选择把这个特性放到了G1之后出现的低延迟垃圾收集器（即ZGC）中。
2.  另外，还考虑到G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。

> **G1 回收器的优化建议**

1.  年轻代大小
    
     *  `避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小`
     *  固定年轻代的大小会覆盖暂停时间目标
2.  `暂停时间目标不要太过严苛 (不要手动设置太低)`
    
     *  G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间
     *  评估G1 GC的吞吐量时，**`暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量`**。

## 8、垃圾回收器总结 `(重点)` ##

### 8.1、`7 种垃圾回收器的比较` ###

> **7 种垃圾回收器的比较**

*  截止JDK1.8，一共有`7`款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点，在具体使用的时候，**需要根据具体的情况选用不同的垃圾收集器**。

![image-20200714075738203][]

1.  GC发展阶段：**`Serial => Parallel（并行）=> CMS（并发）=> G1 => ZGC`**
2.  不同厂商、不同版本的虚拟机实现差距比较大。HotSpot虚拟机在JDK7/8后所有收集器及组合如下图（更新至JDK14）

![image-20200714080151020][]

### 8.2、怎么选择垃圾回收器 ###

> **怎么选择垃圾回收器？**
> 
>  *  **`官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。`**

Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。怎么选择垃圾收集器？

1.  **优先调整堆的大小让JVM自适应完成。**
2.  如果内存小于100M，使用串行收集器
3.  如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
4.  如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
5.  如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器
6.  **`官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。`**

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

最后需要明确一个观点：

1.  没有最好的收集器，更没有万能的收集算法
2.  调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器

> **关于面试**

1.  对于垃圾收集，面试官可以循序渐进从理论、实践各种角度深入，也未必是要求面试者什么都懂。但如果你懂得原理，一定会成为面试中的加分项。
2.  这里较通用、基础性的部分如下：
    
     *  **垃圾收集的算法有哪些？如何判断一个对象是否可以回收？**
     *  **垃圾收集器工作的基本流程。**
3.  另外需要多关注垃圾回收器这一章的各种常用的参数

## 9、GC 日志分析 ##

### 9.1、常用参数配置 ###

> **GC 日志参数设置**

**通过阅读GC日志，我们可以了解Java虚拟机内存分配与回收策略。**

内存分配与垃圾回收的参数列表

1.  \-XX:+PrintGC ：输出GC日志。类似：-verbose:gc
2.  `-XX:+PrintGCDetails ：输出GC的详细日志`
3.  \-XX:+PrintGCTimestamps ：输出GC的时间戳（以基准时间的形式）
4.  \-XX:+PrintGCDatestamps ：输出GC的时间戳（以日期的形式，如2013-05-04T21: 53: 59.234 +0800）
5.  \-XX:+PrintHeapAtGC ：在进行GC的前后打印出堆的信息
6.  \-Xloggc:…/logs/gc.log ：日志文件的输出路径

> **verbose:gc**

*  JVM 参数

-verbose:gc

*  这个只会显示总的GC堆的变化，如下：  
    ![image-20200803105048344][]
 *  参数解析  
    ![image-20200803105115118][]

> **PrintGCDetails**

*  JVM 参数

-XX:+PrintGCDetails

*  输入信息如下  
    ![image-20200803105209534][]
 *  参数解析  
    ![image-20200803105225911][]

> **PrintGCTimestamps 和 PrintGCDatestamps**

*  JVM 参数

-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

*  输出信息如下  
    ![image-20200803105350897][]
 *  说明：日志带上了日期和时间

> **保存日志文件**

*  JVM参数

-XLoggc:./Logs/gc.Log

*  ./ 表示当前目录，在 IDEA中程序运行的当前目录是工程的根目录，而不是模块的根目录

### 9.2、GC 日志参数说明 ###

> **日志分析的补充说明**

1.  `“[GC"和”[Full GC"`说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"Stop The World"
2.  使用`Serial收集器`在新生代的名字是Default New Generation，因此显示的是 **"\[DefNew"**
3.  使用P`arNew收集器`在新生代的名字会变成 **“\[ParNew”**，意思是"Parallel New Generation"
4.  使用`Parallel scavenge收集器`在新生代的名字是 **”\[PSYoungGen"**
5.  老年代的收集和新生代道理一样，名字也是收集器决定的
6.  使用G1收集器的话，会显示为"garbage-first heap"
7.  Allocation Failure表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。
8.  **\[ PSYoungGen: 5986K->696K(8704K) \] 5986K->704K (9216K)**
    
     *  中括号内：GC回收前年轻代大小，回收后大小，（年轻代总大小）
     *  括号外：GC回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）
9.  user代表用户态回收耗时，sys内核态回收耗时，real实际耗时。由于多核线程切换的原因，时间总和可能会超过real时间

> **Young GC 图例**

![image-20200714082555688][]

> **Full GC 图例**

![image-20200714082714690][]

> **GC 代码举例**

*  代码

/** * 在jdk7 和 jdk8中分别执行 * -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC * * @author shkstart shkstart@126.com * @create 2020 0:12 */
    public class GCLogTest1 { 
        private static final int _1MB = 1024 * 1024;
    
        public static void testAllocation() { 
            byte[] allocation1, allocation2, allocation3, allocation4;
            allocation1 = new byte[2 * _1MB];
            allocation2 = new byte[2 * _1MB];
            allocation3 = new byte[2 * _1MB];
            allocation4 = new byte[4 * _1MB];
        }
    
        public static void main(String[] agrs) { 
            testAllocation();
        }
    }

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

**JDK7 中的情况**

*  首先我们会将3个2M的数组存放到Eden区，然后后面4M的数组来了后，将无法存储，因为Eden区只剩下2M的剩余空间了，那么将会进行一次Young GC操作，将原来Eden区的内容，存放到Survivor区，但是Survivor区也存放不下，那么就会直接晋级存入Old 区

![image-20200714083332238][]

*  然后我们将4M对象存入到Eden区中

![image-20200714083526790][]

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

**JDK8 中的情况**

*  程序日志

[GC (Allocation Failure) [DefNew: 6322K->668K(9216K), 0.0034812 secs] 6322K->4764K(19456K), 0.0035169 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     def new generation   total 9216K, used 7050K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  77% used [0x00000000fec00000, 0x00000000ff23b668, 0x00000000ff400000)
      from space 1024K,  65% used [0x00000000ff500000, 0x00000000ff5a71d8, 0x00000000ff600000)
      to   space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
     tenured generation   total 10240K, used 4096K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,  40% used [0x00000000ff600000, 0x00000000ffa00020, 0x00000000ffa00200, 0x0000000100000000)
     Metaspace       used 3469K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

*  **与 JDK7 不同的是，JDK8 直接判定 4M 的数组为大对象，直接放到老年区**

### 9.3、常用日志分析工具 ###

> **常见的日志分析工具**

可以用一些工具去分析这些GC日志，常用的日志分析工具有：

GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等

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

**GCViewer**

![image-20200714084921184][]

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

**GCeasy**

![image-20200714084726824][]

## 10、垃圾回收器的新发展 (`了解`) ##

### 10.1、垃圾回收器的发展过程 ###

> **垃圾回收器的发展过程**

**回首过去**

1.  GC仍然处于飞速发展之中，\`目前的默认选项G1 GC在不断的进行改进，很多我们原来认为的缺点，例如串行的Full GC、Card Table扫描的低效等，都已经被大幅改进，例如，JDK10以后，Fu11GC已经是并行运行，在很多场景下，其表现还略优于ParallelGC的并行Ful1GC实现。
2.  即使是SerialGC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是GC相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在serverless等新的应用场景下，Serial Gc找到了新的舞台。
3.  比较不幸的是CMSGC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除

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

**展望未来**

1.  Epsilon：A No-Op GarbageCollector（Epsilon垃圾回收器，"No-Op（无操作）"回收器），只执行分配，不执行回收，http://openidk.iava.net/ieps/318
2.  ZGC：A Scalable Low-Latency Garbage Collector（Experimental）（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）
3.  现在G1回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器：ZGC（JDK11出现）和Shenandoah（Open JDK12），其特点：主打低停顿时间

### 10.2、Shenandoah GC ###

> **Open JDK12 的 Shenandoah GC**

**Open JDK12的Shenandoash GC：低停顿时间的GC（实验性）**

1.  Shenandoah无疑是众多GC中最孤独的一个。是第一款不由Oracle公司团队领导开发的Hotspot垃圾收集器。不可避免的受到官方的排挤。比如号称openJDK和OracleJDK没有区别的Oracle公司仍拒绝在OracleJDK12中支持Shenandoah。
2.  Shenandoah垃圾回收器最初由RedHat进行的一项垃圾收集器研究项目Pauseless GC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDK。
3.  Red Hat研发Shenandoah团队对外宣称，Shenandoah垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为200MB还是200GB，99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。

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

这是RedHat在2016年发表的论文数据，测试内容是使用ES对200GB的维基百科数据进行索引。从结果看：

1.  停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。
2.  而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。

![image-20200714090608807][]

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

总结

1.  Shenandoah GC的弱项：高运行负担下的吞吐量下降。
2.  Shenandoah GC的强项：低延迟时间。

### 10.3、革命性的 `ZGC` (重要) ###

> **令人震惊、革命性的 ZGC**

1.  官方文档：https://docs.oracle.com/en/java/javase/12/gctuning/
2.  ZGC与Shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟。
3.  《深入理解Java虚拟机》一书中这样定义ZGC：**`ZGC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。`**
4.  **ZGC的工作过程可以分为4个阶段：`并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射`** 等。
5.  ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的。

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

**吞吐量**

![image-20200714091201073][]

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

**暂停时间**

![image-20200714091401511][]

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

1.  虽然ZGC还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用“令人震惊、革命性”来形容，不为过。
2.  **未来将在服务端、大内存、低延迟应用的首选垃圾收集器。**

![image-20200714093243028][]

> **JDK14 新特定：ZGC**

1.  JDK14之前，ZGC仅Linux才支持。
2.  尽管许多使用ZGC的用户都使用类Linux的环境，但在Windows和macOS上，人们也需要ZGC进行开发部署和测试。许多桌面应用也可以从ZGC中受益。因此，ZGC特性被移植到了Windows和macOS上。
3.  现在mac或Windows上也能使用ZGC了，示例如下：

-XX:+UnlockExperimentalVMOptions-XX：+UseZGC

### 10.4、面向大堆的 AliGC ###

> **其他回收器：AliGC (下面和G1的对比图, 也不行啊)**

AliGC是阿里巴巴JVM团队基于G1算法，面向大堆（LargeHeap）应用场景。指定场景下的对比：

![image-20200714093604012][]

[image-20200713215105293]: /images/20221119/b59475f662b54525a3b36d1956bdc063.png
[image-20200713215133839]: /images/20221119/a78b2f76c2864b7da45857b47082c0ee.png
[image-20200713223244886]: https://img-blog.csdnimg.cn/img_convert/e65f13ce270aed9b0479e6bbdb14f753.png
[image-20200713223509993]: https://img-blog.csdnimg.cn/img_convert/e52dd44093d20e7b3388b8f636afa99d.png
[image-20200713224113996]: https://img-blog.csdnimg.cn/img_convert/e5725e832887bdcbbcd586389b01e432.png
[image-20200713224716715]: https://img-blog.csdnimg.cn/img_convert/f8536319e1a23157b7928ebde5514800.png
[image-20200713225100632]: https://img-blog.csdnimg.cn/img_convert/9a15dfdadedc3fcc24a5e7e1ba1c11a4.png
[image-20200713225810871]: https://img-blog.csdnimg.cn/img_convert/cc01da5dd04044ee561db4c51b850461.png
[image-20200714075738203]: https://img-blog.csdnimg.cn/img_convert/7d90e93076399298712683e0cbd7c134.png
[image-20200714080151020]: https://img-blog.csdnimg.cn/img_convert/4b6315480ee33684ce90cf78798402f4.png
[image-20200803105048344]: https://img-blog.csdnimg.cn/img_convert/9eca39e8d3c573ce6f7260eecb58570c.png
[image-20200803105115118]: https://img-blog.csdnimg.cn/img_convert/9bdd3eaa84590e11cd2df43a87d4ac34.png
[image-20200803105209534]: https://img-blog.csdnimg.cn/img_convert/43b3421d2cc8ea75fa71a42f7588a01d.png
[image-20200803105225911]: https://img-blog.csdnimg.cn/img_convert/228ebb3b33ae70c6f5861f4508169a3a.png
[image-20200803105350897]: https://img-blog.csdnimg.cn/img_convert/069e3427bdbdc443392d25d5bf1b7029.png
[image-20200714082555688]: https://img-blog.csdnimg.cn/img_convert/f55e38bbf3c99d20ce57f8186d2c2ca8.png
[image-20200714082714690]: https://img-blog.csdnimg.cn/img_convert/d7f14eead4d8be10c0b4112ef1c0bc50.png
[image-20200714083332238]: https://img-blog.csdnimg.cn/img_convert/da6f29b7ab83b112c54afb9db42b28e2.png
[image-20200714083526790]: https://img-blog.csdnimg.cn/img_convert/ca68b30f95a2650ceedf1a9f16690528.png
[image-20200714084921184]: https://img-blog.csdnimg.cn/img_convert/dc513f550091e20b8fbe10f758637aa4.png
[image-20200714084726824]: https://img-blog.csdnimg.cn/img_convert/eef98fdbb7f0cd2e4bc3e7c1bc92a840.png
[image-20200714090608807]: https://img-blog.csdnimg.cn/img_convert/c3642c027f8bccb8e9c9493a62353af4.png
[image-20200714091201073]: https://img-blog.csdnimg.cn/img_convert/06ac38247c6cd4202c08603804f4fdd0.png
[image-20200714091401511]: https://img-blog.csdnimg.cn/img_convert/934db937d1c392837bff756c22dd8133.png
[image-20200714093243028]: https://img-blog.csdnimg.cn/img_convert/60f17aa2bf7fa9beb401acc3458a1cf9.png
[image-20200714093604012]: https://img-blog.csdnimg.cn/img_convert/8455dea4d99839890f28a2048007e477.png