JVM经典垃圾收集器

JVM经典垃圾收集器

各垃圾收集器之间的关系：（两个垃圾收集器之间有连线，说明是可以搭配使用的）

(1)Serial收集器（新生代垃圾收集器）

①该收集器是一个单线程工作的收集器
②新生代采用复制算法；老年代采用标记整理算法此时都会STW
③垃圾收集运行过程

④优点：是简单而高效（与其他收集器的单线程相比），对于内存资源受限的环境，它是所有收集器里额外内存消耗（Memory Footprint）[1]最小的；对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

(2)ParNew收集器（Serial收集器的多线程并行版本注意这里并不是并发的可达性分析）

①该垃圾收集器除了多线程以外其余的算法、策略、配置都十分相似。
②运行过程：

③该垃圾收集器是不少运行在服务端模式下的HotSpot虚拟机。具体原因：除了Serial收集器外，目前只有它能与CMS收集器（老年代垃圾收集器）配合工作。
④并发与并行的概念：
1)并行（Parallel）：并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线程在协同工作，通常默认此时用户线程是处于等待状态。
2)并发（Concurrent）：并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行。由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。

(3)Parallel Scavenge收集器（注重吞吐量的垃圾收集器）（新生代垃圾收集器）（不能与CMS搭配使用）

①特点：而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值，

②垃圾收集算法：复制算法
③主要适用场景：高吞吐量则可以最高效率地利用处理器资源，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的分析任务。
④用于精确控制吞吐量的参数：
1)-XX：MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过用户设定值。
2)-XX：GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。
⑤垃圾收集的自适应调节：Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy值得我们关注。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

(4)Serial Old 收集器（老年代的Serial收集器）

①主要也是提供客户端模式下的HotSpot虚拟机使用。
②用途：
1)一种是在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用。
2)种就是作为CMS收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。
③运行示意图

(5)Parallel Old收集器（Parallel 老年代收集器）
①工作运行流程：

(6)CMS垃圾收集器（以获取最短回收停顿时间为目标的收集器）
①基于标记-清除算法实现的。
②运行流程：
1)初始标记（SWT）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
2)并发标记：是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。（并发的可达性分析）（耗时最长）
3)重新标记(STW)：而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。（并发标记时发生的一些引用关系的改变，CMS使用的是增量更新方法来进行重新标记）
4)并发清除：清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。（耗时最长）

③优点：低停顿
④缺点：
1)对处理器资源非常敏感
2)由于CMS收集器无法处理浮动垃圾，会出现收集时报导致Full GC
3)会产生大量的空间碎片

(7)G1垃圾收集器（面向局部收集）

①该收集器是面向服务端运用的垃圾收集器
②该垃圾收集器实现了“停顿时间模型”（能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间大概率不超过N毫秒这样的目标，这几乎已经是实时Java（RTSJ）的中软实时垃圾收集器特征了。）
③G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
④G1中的新生代和老年代是一个动态集合。Region作为单次回收的最小单元。

⑤G1中每个Region都维护有自己的记忆集，这些记忆集会记录下别的Region指向自己的指针。
⑥对于并发标记的处理，G1采用原始快照的方法来进行处理。
⑦用户通过-XX：MaxGCPauseMillis参数指定的停顿时间只意味着垃圾收集发生之前的期望值，（G1收集器的停顿预测模型是以衰减均值（Decaying Average））
⑧这里强调的“衰减平均值”是指它会比普通的平均值更容易受到新数据的影响，平均值代表整体平均状态，但衰减平均值更准确地代表“最近的”平均状态。
⑨运行的四个步骤：

1)初始标记（Initial Marking）：(STW)仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
2)并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
3)最终标记（Final Marking）：(STW)对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
4)筛选回收（Live Data Counting and Evacuation）：（STW）负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。（停顿的原因：考虑到G1只是回收一部分Region，停顿时间是用户可控制的，所以并不迫切去实现，而选择把这个特性放到了G1之后出现的低延迟垃圾收集器（即ZGC）中。另外，还考虑到G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。通过图3-13可以比较清楚地看到G1收集器的运作步骤中并发和需要停顿的阶段。）
⑩G1整体是使用的标记整理算法而局部看是复制算法。
⑪G1适用于大内存的场景；CMS适用于小内存的场景。