JVM学习笔记-垃圾回收器

曾经终败给现在 2023-01-15 14:24 181阅读 0赞

HotSpot虚拟机所包含的收集器：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk4MTMxNQ_size_16_color_FFFFFF_t_70]

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

几个相关概念：

>  *  **并行收集：** 指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
>  *  **并发收集：** 指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。
>  *  **吞吐量：** 即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

## 一、Serial（串行垃圾回收器） ##

**1、serial回收器**（应用于新生代）

> Serial收集器是最基本的、发展历史最悠久的收集器。
> 
> **特点：** 单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。  
> **应用场景：** 适用于Client模式下的虚拟机。

**2、serial old回收器**（应用于老年代）

> Serial Old是Serial收集器的老年代版本。
> 
> **特点：** 同样是单线程收集器，采用标记-整理算法。
> 
> **应用场景：** 主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。

![在这里插入图片描述][20210422222213203.png]

## 二、并行垃圾回收器 ##

**1、parNew**（新生代）

> ParNew收集器其实就是Serial收集器的多线程版本。除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。  
> **特点：** 多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。  
> **缺点：** 和Serial收集器一样存在Stop The World问题  
> **应用场景：** ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。  
> ![在这里插入图片描述][20210422222718688.png]

**2、parallel Scavenge 收集器** (新生代）

> 与吞吐量关系密切，故也称为吞吐量优先收集器。  
> **特点：** 属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。  
> 该收集器的**目标是达到一个可控制的吞吐量**。还有一个值得关注的点是：**GC自适应调节策略**（与ParNew收集器最重要的一个区别）  
> GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

**3、Parallel Old 收集器** （老年代）

> 是Parallel Scavenge收集器的老年代版本。  
> **特点：** 多线程，采用标记-整理算法。  
> **应用场景：** 注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。  
> ![在这里插入图片描述][20210422222833931.png]

## 三、CMS收集器 ##

> 一种以获取最短回收停顿时间为目标的收集器。
> 
> **特点：** 基于标记-清除算法实现。**并发收集**、低停顿。
> 
> **应用场景：** 适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。
> 
> CMS收集器的运行过程分为下列4步：
> 
>  *  **初始标记：** 标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。
>  *  **并发标记：** 进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。
>  *  **重新标记：** 为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。
>  *  **并发清除：** 对标记的对象进行清除回收。  
>     注意： CMS收集器的内存回收过程是与用户线程一起**并发执行**的。  
>     ![在这里插入图片描述][20210422223237993.png]

## 四、G1收集器 ##

> G1从整体看还是基于标记-清除算法的，但是局部上是基于复制算法的。这样就意味者它空间整合做的比较好，因为不会产生空间碎片。G1还是并发与并行的，它能够充分利用多CPU、多核的硬件环境来缩短“stop the world”的时间。G1还是分代收集的，但是G1不再像上文所述的垃圾收集器，需要分代配合不同的垃圾收集器，因为G1中的垃圾收集区域是“分区”（Region）的。G1的分代收集和以上垃圾收集器不同的就是除了有年轻代的ygc，全堆扫描的fullGC外，还有包含所有年轻代以及部分老年代Region的Mixed GC。G1还可预测停顿，通过调整参数，制定垃圾收集的最大停顿时间。  
> G1收集器的运作大致可以分为以下步骤： **初始标记、并发标记、最终标记、筛选回收。** 其中  
> **初始标记阶段：** 仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Set）的值，让下一个阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这个阶段需要STW，但耗时很短。  
> **并发标记阶段:** 是从GC Roots开始对堆中对象进行可达性分析，找到存活的对象，**这阶段耗时较长**，但是可以和用户线程并发运行。  
> **最终标记阶段：** 为了修正在并发标记期间因用户程序继续运行而导致标记产生变化的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记需要把Remembered Set Logs的数据合并到Remembered Sets中，这阶段需要暂停线程，但是**可并行执行**。  
> **筛选回收阶段：** 首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来确定回收计划。回收过程为对存活对象复制到空的区域，再清除掉整个旧的空间，需要stop the world。

**特点如下：**

> **并行与并发：** G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。
> 
> **分代收集：** G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
> 
> **空间整合：** G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。
> 
> **可预测的停顿：** G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

**分区模型：**

> Eden regions(年轻代-Eden区)；  
> Survivor regions(年轻代-Survivor区)；  
> Old regions（老年代）；  
> Humongous regions（巨型对象区域）；  
> Free regions（未分配区域，也会叫做可用分区）-上图中空白的区域  
> ![> 在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk4MTMxNQ_size_16_color_FFFFFF_t_70 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk4MTMxNQ_size_16_color_FFFFFF_t_70]: /images/20221022/682d16d0647a415ab60847dbf4da0b70.png
[20210422222213203.png]: /images/20221022/787cddfba567401abd37c881d7c2c3b5.png
[20210422222718688.png]: /images/20221022/15bb05c841014b8bbc70767a1f82271b.png
[20210422222833931.png]: /images/20221022/f154e6ace6fc4535b9429e3bc3c3b6a6.png
[20210422223237993.png]: /images/20221022/daf8c815eb6c4963a8327933e331c731.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk4MTMxNQ_size_16_color_FFFFFF_t_70 1]: /images/20221022/2ff0479501b04e2599be86a1c0a51af3.png