【006】【JVM——垃圾收集器总结】



Java虚拟机学习总结文件夹

JVM——垃圾收集器总结

垃圾收集器概览

收集算法是内存回收的方法论。垃圾收集据是内存回收的详细实现。Java虚拟机规范中对垃圾收集器应该怎样实现没有规定。不同的厂商、不同版本号的虚拟机所提供的垃圾收集器可能会有非常大区别。一般都会提供參数供用户依据自己的所用特点和要求组合出各个年代所使用的收集器。

以下是基于JDK
1.7 Update 14 之后的HotSpot 虚拟机垃圾收集器。

假设两个收集器之间有连线就说明它们能够搭配使用。直到如今还没有最好的收集器。更加设有万能的收集器。仅仅是对详细应用选择最合适的收集器。

垃圾收集器概览图例如以下：

Serial 收集器

Serial 收集器是最基本、历史最悠久的收集器，它是一个单线程的收集器，即它仅仅会使用一个CPU 或一条收集线程去完毕垃圾收集工作，并且在进行垃圾收集时， 必须暂停其它全部的工作钱程，直到它收集结束。尽管它有非常大缺点，但依旧是虚拟机执行在Client 模式下的默认新生代收集器。

它也有着优于其它收集器的地方： 简单而高效。Serial 收集器没有线程交互的开销。 专心做垃圾收集，能够获得非常高的单线程收集效率。

执行示意图例如以下：

ParNew 收集器

ParNew 收集器事实上就是Serial收集器的多线程版本号。除了使用多条线程进行垃圾收集之外，其余行为包含Serial 收集器可用的全部控制參数、、收集算法、应用停机（Stop
The World）、对象分配规则、回收策略等都与Serial 收集器全然一样。ParNew是很多执行在Server 模式下的虚拟机中首选的新生代收集器。眼下仅仅有它能与CMS 收集器配合工作。ParNew 收集器在单CPU 的环境中不会有比Serial 收集器效果好。随着使用的CPU 的数量的添加，它对于GC 时系统资源的利用提高。

垃圾收集的上下文语境中：

• 并行（ Parallel ）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

• 并发（ Concurrent ）：指用户线程与垃圾收集线程同一时候执行（但不一定是并行的，可能会交替执行），用户程序继续执行。垃圾收集程序执行在还有一个CPU 上。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvREVSUkFOVENN/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

Parallel Scavenge 收集器

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

Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量。吞吐量就是CPU 用于执行用户代码的时间与CPU 总消耗时间的比值，即 吞吐量＝执行用户代码时间／（ 执行用户代码时间＋垃圾收集时间）。

高吞吐量能够最高效率地利用CPU 时间，尽快地完毕程序的运算任务。主要适合在后台运算而不须要太多交互的任务。Parallel Scavenge 收集器也常常称为“吞吐量优先”收集器。

Serial Old 收集器

Serial Old 是Serial 收集器的老年代版本号。 也是一个单线程收集器，使用“标记一整理”算法。主要被Client 模式下的虚拟机使用。

假设在Server 模式下，有两大用途： 一个是在JDK
5 以及之前的版本号中与Parallel Scavenge 收集器搭配使用。还有一个就是作为CMS 收集器的后备预案，在并发收集发生Concurrent
Mode Failure 的时候使用。

执行示意图例如以下：

Parallel Old 收集器

Parallel Old 是Parallel Scavenge 收集器的老年代版本号，使用多线程和“标记一整理”算法。

执行示意图例如以下：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvREVSUkFOVENN/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

CMS 收集器

CMS（ Concurrent Mark Sweep ） 收集器是一种以获取最短回收停顿时间为目标的收集器。停顿时间越短就越适合须要与用户交互的程序。良好的响应速度能提升用户体验。眼下非常大一部分的Java 应用都集中在互联站点或B/S 系统的服务端上。这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

CMS 收集器就非常符合这类应用的需求。

CMS 收集器是基于“标记一清除”算法实现的，整个过程分为4 个步骤：

1. 初始标记（ CMS initial mark): 须要“Stop
   The World ”。

   初始标记只不过标记一下GC Roots 能直接关联到的对象，速度非常快。

2. 并发标记（ CMS concurrent mark)：并发标记阶段就是进行GCRoots
   Tracing 的过程

3. 又一次标记（ CMS remark) : 须要“Stop
   The World ”。为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些。但远比并发标记的时间短

4. 并发清除（ CMS concurrent sweep)：进行垃圾清理工作。

执行示意图例如以下：

长处：并发收集、低停顿。

缺点：

CMS 收集器对CPU 资源很敏感。在并发阶段。它尽管不会导致用户线程停顿，可是会由于占用了一部分线程（或者说CPU 资源）而导致应用程序变慢，总吞吐量会减少。

CMS 默认启动的回收线程数是（CPU 数量＋3）/
4 。

CMS 收集器无法处理浮动垃圾（ Floating
Garbage ）。可能出现“Concurrent Mode Failure”，失败而导致还有一次Full GC 的产生。

CMS 并发清理阶段用户线程还在执行着，伴随程序的执行会有新的垃圾产生，这一部分垃圾出如今又一次标记过程之后， CMS 无法在本次收集中处理它们，仅仅仅仅留待下一次GC 时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。

因为在垃圾收集阶段用户线程还须要执行，就要预留足够的内存空间给用户线程使用，因此CMS 收集器不能像其它收集器那样等到老年代差点儿全然被填满了再进行收集，CMS 收集器须要预留一部分空间提供并发收集时的程序运作使用。

要是CMS 执行期间预留的内存无偿满足程序须要，就会出现一次“Concurrent
Mode Failure 失败。这时虚拟机将启动后备预案：暂时启用Serial Old 收集器来又一次进行老年代的垃圾收集，会停顿较长时间。

收集结束时会产生大量空间碎片。

CMS 基于“标记一清除”算法实现。

多次垃圾收集后，空间碎片过多，给大对象分配带来非常大的麻烦，往往会出现老年代还有非常大的空间剩余，可是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full
GC 。为了解决问题， CMS 收集器提供了-XX:+UseCMSCompactAtFullCollection 这个參数，用于在CMS收集器要进行FullGC时开启内存碎片整理。默认值为0，表示每次进入FullGC 时都进行碎片整理

G1 收集器

收集器技术发展的最新成果。是面向服务端应用的垃圾回收器。它有以下的特点：

• 并发与并行：能利用多CPU、多核环境下优势，使用多个CPU
  (CPU或者CPU 核心)来缩短Stop The World 的停顿时间。部分其它收集器原本须要停顿Java 线程运行的GC动作。 G1 收集器仍然能够通过并友的方式让Java 程序继续运行

• 分代收集：G1中依然使用分代概念。G1可以不须要其它收集器配合就能独立管理整个GC 堆，还可以用不同的方式去处理新创建的对象和已经存在一段时间、经过多次GC 依然存在的对象，进而获得更好的收集效果．

• 空间整合：GI从总体来看是基于“标记一整理”算法， 从局部（两个Region 之间）后是基于“复制” 算法实现的，这意味着GI1执行期间不会产生内存空间碎片，收集后能提供规整的可用内存． 这样的特性有利于程序长时间执行。分配大的对象不会由于无法找到连续内存空间而提前触发下一次GC。

• 可预測的停顿：GI 除了低停顿外，还能建立预測的停顿时间的模型，能让使用者明白指定在一个长度为M 毫秒的时间片段内。垃圾收的时间不得超过N 毫秒。

使用GI 收集器时。Java 堆的内存布局就与其它收集器有非常大区别。它将整个Java 堆划分为多个大小相等的独立区域（Region），尽管保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离，它们都是一部分Region（不须要连续）的集合。

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

在GI 收集器中， Region 之间的对象引用以及其它收集器中的新生代与老年代之间的对象引用， 虚拟机都是使用Remembered
Set 来避免全堆扫描。

不计算维护Remembered Set 的操作。 GI收集器的运作可划分为下面四个步骤：

1. 初始标记（Initial Marking）：仅标记GC
   Roots能直接关联到的对象而且改动TAMS（Next to Top at Mark Start）的值。让下一阶段用户程序并发执行时。能在正确可用的Region中创建新对象。这个阶段要停顿线程。但耗时短。

2. 并发标记（Concurrent Marking）：从GC
   Roots開始对堆中对象进行可达性分析，找出存活对象，这个阶段耗时少，能够与用户程序并发运行。

3. 终于标记（Final Marking）：为了修正并发标记期间。因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。虚拟机将这段时间变化记录在线程Remembered
   Set中，这个阶段能够并行运行。

4. 筛选回收（Live Data Counting and Evacuation）：对各个Region的回收价值和成本进行排序。依据用户所期望的GC停顿时间来制定回收计划，能够与用户程序并发运行。

执行示意图例如以下：

【參见】【深入理解Java虚拟机（第二版）】【周志明】