yangl的博客

积少成多

0%

jvm(HotSpot)的垃圾回收器

发表于 更新于 分类于 Valine：
本文字数： 3k 阅读时长 ≈ 3 分钟

jvm垃圾的回收作用范围

下面描述的收集器是基于 JDK1.7 Update 14 之后的 HotSpot 虚拟机，这个虚拟机包含的所有收集器如下图：如果两个收集器之间存在连线，就说明他们可以搭配使用。

1610272098369

jvm的7种垃圾回收器

1.Serial收集器(单线程)

Serial收集器时最基本、发展历史最悠久的收集器。是单线程的收集器。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集完成。
Serial收集器依然是虚拟机运行在Cleent模式下默认新生代收集器，对于运行在Client模式下的虚拟机来说是一个很好的选择。

2.ParNew收集器（Serial+多线程）

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Worl、对象可分配规则、回收策略等都与Serial收集器完全一样。
ParNew收集器是许多运行在Server模式下的虚拟机中首选新生代收集器，其中有一个与性能无关但很重要的原因是除了Serial收集器之外，目前只有arNew它能与CMS收集器配合工作。

3.Parallel Scavenge(并行回收)收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器

该收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）
停顿时间越短就越适合需要与用户交互的程序良好的响应速度能提升用户体验，二高吞吐量则可用高效率的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算二不需要太多的交互的任务。

Parallel Scavenga收集器提供两个参数用于精确控制吞吐量，分别是控制最大垃圾收起停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数

Parallel Scavenge收集器还有一个参数：-XX:+UseAdaptiveSizePPolicy/这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor去的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数，只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGvPauseMillis参数或者SGCTimeRation参数给虚拟机设立一个优化目标。

自适应调节策略也是paralel Scavenge收集器与ParNew收集器的一个重要区别

4.Serial Old收集器

Serial Old 是 Serial 收集器的老年代版本，它同样是一个单线程收集器，使用标记清除算法。这个收集器的主要意义也是在于给 Client 模式下的虚拟机使用。

如果在 Server 模式下，主要两大用途：

  1. 在 JDK1.5 以及之前的版本中与 Parallel Scavenge 收集器使用
  2. 作为 CMS 收集器的后备预案，在并行收集发生 Concurrent Mode Failure 时使用

5.Paralled Old收集器

Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和“标记-清理”算法。这个收集器在 1.6 中才开始提供。

6.CMS收集器

CMS（ Concurrent Mark Sweep ） 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务器的相应速度，希望系统停顿时间最短，已给用户带来较好的体验。 CMS 收集器就非常符合这类应用需求

CMS 收集器是基于“标记-清除”算法实现的。它的运作过程相对前面几种收集器来说更加复杂一些，整个过程为4个步骤:

  1. 初始标记
  2. 并发标记
  3. 重新标记
  4. 并发清除

其中，初始标记、重新标记这两个步骤仍然需要 “Stop the World”。

CMS 收集器的主要优点：并发收集，低停顿。

CMS 三个明显的缺点：

  1. CMS 收集器对 CPU 资源非常敏感。 CPU 个数少于4个时， CMS 对于用户程序的影响就可能变得很大，为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”的 CMS 收集器变种。所做的事情和单 CPU 年代 PC 机操作系统使用抢占式来模拟多线程任务机制的思想。
  2. CMS 收集器无法处理浮动垃圾，可能出现“ Concurrent Mode Failure ”失败而导致另一次 Full Gc 的产生。在 JDK1.5 的默认设置下， CMS 收集器当老年代使用了 68% 的空间后就会被激活， 这是一个偏保守的设置， 如果在应用中老年代增长不是太快，可以适当调高参数 -XX:CMSInitiatingOccupancyFraction 的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在 JDK1.6 中， CMS 收集器的启动阈值已经提升到 92%。
  3. CMS 是基于“标记-清除”算法实现的收集器，手机结束时会有大量空间碎片产生。空间碎片过多，可能会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前发出 Full Gc。为了解决这个问题， CMS 收集器提供一个 -XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在 CMS 收集器顶不住要进行 FullGC 时开启内存碎片整合并清理过程， 内存整理的过程是无法并发的，空间碎片问题没有了，但是停顿时间变长了。虚拟机设计者还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction ，这个参数是用于设置执行多次不压缩 Full GC后，跟着来一次带压缩的FullGC（默认值为0，标识每次进入 FullGC时都进行碎片整理）

7.G1收集器

G1收集器的优势：

  1. 并行与并发
  2. 分代收集
  3. 空间整理（标记整理算法，复制算法）
  4. 可预测的停顿（G1处追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M毫秒的时间片段内，消耗在垃圾收集器上的时间不超过 N 毫秒，这几乎已经实现 Java（ RTSJ ）的垃圾收集器的特征）

使用 G1 收集器时， Java 堆的内存布局是整个规划为多个大小相等的独立区域（ Region ），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一小部分 Region 的集合。

G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个 Java 堆中进行全区域的垃圾收集。 G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获取的空间大小以及回收所需要的时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先收集价值最大的 Region （这也就是 Garbage-First 名称的由来）。这种使用 Region 划分的内存空间以及优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽量可能高的效率。

G1 内存“化整为零”的思路

在 GC 根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会遗漏。

如果不计算维护 Remembered Set 的操作， G1 收集器的运作大致可分为以下步骤：

  1. 初始标记
  2. 并发标记
  3. 最终标记
  4. 筛选回收

----------- 本文结束啦感谢您阅读 -----------