复习整理篇-JVM垃圾回收器

垃圾回收器

---

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

图片来自：https://www.cnblogs.com/chenpt/p/9803298.html

1.Serial收集器使用复制算法

Serial收集器是最基本、发展历史最悠久的收集器。

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

2.ParNew收集器使用复制算法

ParNew收集器其实就是Serial收集器的多线程版本。

• 特点：多线程、ParNew收集器收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。和Serial收集器一样存在Stop the World问题。
  除了使用多线程外其余行为和Serial收集器一模一样（参数控制、收集算法、Stop the World、对象分配原则、回收策略等）
• 应用场景：ParNew收集器是许多运行在Server模式下的虚拟机首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

3.Parallel Scavenge收集器使用复制算法

与吞吐量关系密切，故也称吞吐量优先收集器。

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

4.Serial Old收集器使用标记-整理算法

Serial Old收集器是Serial收集器的老年代版本。

• 特点：同样是单线程收集器，采用标记-整理算法
• 应用场景：主要也是使用在Client模式下的虚拟机中，也可以在Server模式下使用。
  Server模式下的两大用途：
  ①在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用
  ②作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。
  并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行可能会交替执行）。用户程序在继续运行，而垃圾收集器程序运行在另一个CPU上。

5.Parallel Old收集器使用复制算法

是Parallel Scavenge收集器的老年代版本。

• 特点：多线程，采用复制算法
• 应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old收集器。

6.CMS收集器使用标记-清除算法

一种以获取最短回收停顿时间为目标的收集器。

• 特点：基于标记-清除算法实现。并发收集、低停顿。
• 应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。
  CMS收集器的运行过程分为下列4步：
  ①初始标记：标记GC Roots能直接到的对象，速度很快但是仍存在Stop the World问题；
  ②并发标记：进行GC Roots Tracing的过程，找出存活对象且用户线程可并发执行；
  ③重新标记：为了修正并发标记期间因用户程序继续运行导致标记产生变动的那一部分对象的标记记录。仍然存在Stop the World问题；
  ④并发清除：对标记的对象进行清除回收。
  在java语言中，可作为GC Roots的对象包括：
  （1）虚拟机栈（栈帧中的本地变量表）中引用的对象
  （2）方法区中类静态属性引用的对象
  （3）方法区中常量引用的对象
  （4）本地方法栈中JNI（即一般说的native方法）引用的对象
  CMS收集器的缺点：
  a.对CPU资源非常敏感
  b.无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生
  c.因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配问题，不得不提前触发一次Full GC

7.G1收集器

一款面向服务端应用的垃圾收集器。

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

  G1收集器大致可分为如下步骤：
  ①初始标记：仅标记GC Roots能够直接到的对象，并且修改TAMS(Next Top at Mask Start)的值，让下一阶段用户程序并发执行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短）
  ②并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）
  ③最终标记：为了修正并发标记期间因用户程序继续运行导致标记产生变动的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面。（需要线程停顿，但可并发执行）
  ④筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）