说一说JVM的垃圾回收器

我不是女神ヾ 2024-03-27 09:26 96阅读 0赞

#### 垃圾回收器 ####

*  1.Serial收集器
 *  2.parnew收集器
 *  3 .parallel Scavenge收集器
 *  4.Serial Old
 *  5.parallel old收集器
 *  6.cms
 *  7. G1 收集器

**串行：指的是垃圾回收器与用户线程交替进行，这意味着在垃圾回收器执行的时候用户线程需要暂停工作  
并行：指的是垃圾回收器和用户线程同时执行，除了cms和G1之外其它垃圾回收器都是以串行的方式执行的**

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

## 1.Serial收集器 ##

> Serial翻译为串行，也就是说它以串行的方式执行，它是单线程的收集器，只会使用一个线程进行垃圾回收工作  
> 优点是简单高效，对于单个cpu环境来说，没有线程切换的开销，收集率高  
> 它是client（客户端）模式下默认的垃圾回收器

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

## 2.parnew收集器 ##

> 它是serial收集器的多线程版本，是server模式下的虚拟机首选新生代收集器，除了性能原因外，主要原因是除了serial收集器，只有它能与cms收集器配合工作  
> 默认开启的线程数量与cpu数量相同，可以与-xx：parallelGCThreads参数来设置线程数

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

## 3 .parallel Scavenge收集器 ##

> 与parnew一样是多线程收集器  
> 其它收集器关注点是尽可能缩短垃圾回收时用户线程的停顿时间，而他的目标是达到一个可控制的吞吐量，它被称为吞吐量优先收集器，这里吞吐量值得是cpu用于运行用户代码的时间占总时间的比值  
> 停顿时间越短就越适合需要与用户交互的应用程序，良好的响应速度能提升用户体验，而高吞吐量可以高效利用cpu时间，尽快完成任务缩短停顿时间是以牺牲吞吐量和新生代空间来换取的: 新生代空间变小，垃圾回收变得频繁，导致吞吐量下降。可以通过一个开关参数打开 GC 自适应的调节策略(GC Ergonomics)，就不需要手动指定新生代的大小(-Xmn)、Eden 和 Survivor 区的比例、晋升老年代对象年龄等细节参数了。虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

## 4.Serial Old ##

> 是serial收集器的老年代版本，也是给client模式下的虚拟机使用的，如果在server模式下，它有两大用途：

*  在jdk1.5以及之前的版本（parallel old诞生以前）中与parallel收集器搭配使用
 *  作为cms收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

## 5.parallel old收集器 ##

> 是parallel scavenge收集器的老年版本  
> 在注重吞吐量以及cpu资源敏感的场合优先考虑parallel Scavenge 加parallel old收集器

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

## 6.cms ##

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

> Concurrent Mark Sweep，Mark Sweep指的是标记-清除算法  
> 分为以下四个流程：

*  初始标记：仅仅标记一下GC root能直接相关的对象，速度快，需要停顿
 *  并发标记：进行GC root Tracing的过程，它在整个回收过程中耗时最长，不需要停顿
 *  重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿。
 *  并发清除: 不需要停顿。

> 在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。具有以下缺点:吞吐量低: 低停顿时间是以牺牲吞吐量为代价的，导致 CPU 利用率不够高。无法处理浮动垃圾，可能出现 Concurrent Mode Failure。浮动垃圾是指并发清除阶段由于用户线程继续运行而产生的垃圾，这部分垃圾只能到下一次 GC 时才能进行回收。由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。标记 - 清除算法导致的空间碎片，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC。

## 7. G1 收集器 ##

> G1(Garbage-First)，它是一款面向服务端应用的垃圾收集器，在多 CPU 和大内存的场景下有很好的性能。HotSpot 开发团队赋予它的使命是未来可以替换掉 CMS 收集器。堆被分为新生代和老年代，其它收集器进行收集的范围都是整个新生代或者老年代，而 G1 可以直接对新生代和老年代一起回收。

G1 把堆划分成多个大小相等的独立区域(Region)，新生代和老年代不再物理隔离

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

通过引入 Region 的概念，从而将原来的一整块内存空间划分成多个的小空间，使得每个小空间可以单独进行垃圾回收。这种划分方法带来了很大的灵活性，使得可预测的停顿时间模型成为可能。通过记录每个 Region 垃圾回收时间以及回收所获得的空间(这两个值是通过过去回收的经验获得)，并维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。每个 Region 都有一个 Remembered Set，用来记录该 Region 对象的引用对象所在的 Region。通过使用 Remembered Set，在做可达性分析的时候就可以避免全堆扫描。

> 如果不计算维护 Remembered Set 的操作，G1 收集器的运作大致可划分为以下几个步骤:初始标记并发标记最终标记: 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中。这阶段需要停顿线程，但是可并行执行。筛选回收: 首先对各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。具备如下特点:空间整合: 整体来看是基于“标记 - 整理”算法实现的收集器，从局部(两个 Region 之间)上来看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。可预测的停顿: 能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在 GC 上的时间不得超过 N 毫秒。

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

[03897fe02de04efdbd15f2d6423adf3b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/8cb16aa5a9c64302b9beacacf23373db.png
[76fb157ad91d4744915cb66768aab688.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/57f421bb4ba34038a5c52b453989a982.png
[e257db5c20cf425e9d9e41f500dd11b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/fe8e55e8f0fe4151acd3df814081eeab.png
[3a896a712e9d4855b5c2d2d5e4d95ec9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/b8f3aa0657f541aa9c794c3a3a665af1.png
[287f361a089a4b8291466f039ff2d936.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/696d670bb8e449f19d82dcb65b493664.png