jvm总结三《垃圾收集器》

本文内容：
serial收集器、parNew收集器、parallel scavenge收集器、serial old收集器、CMS收集器、G1收集器

serial收集器

Serial（串行）垃圾收集器是最基本、发展历史最悠久的收集器，新生代收集器

特点

• 针对新生代；
• 采用复制算法；
• 单线程收集；
• 适用CPU
• 进行垃圾收集时，必须暂停所有工作线程，直到完成；
• 即会"Stop The World"

应用场景

Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。

Stop TheWorld说明

JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿；会带给用户不良的体验；从JDK1.3到现在，从Serial收集器-》Parallel收集器-》CMS-》G1，用户线程停顿时间不断缩短，但仍然无法完全消除；

图文说明

serial old收集器

serial old和serial一样都是但线程GC收集器，老年代收集器

特点

• 针对老年代；
• 采用标记整理算法；
• 单线程收集；
• 进行垃圾收集时，必须暂停所有工作线程，直到完成；
• 即会"Stop The World"

应用场景

主要也是给client模式下使用的
如果作用在server模式下，那么它有两个用途：

• 在jdk1.5之前的版本中与parallel scavenge收集器搭配使用
• 做为CMS收集器的后备预案，在并发收集发生 concurrent mode failure时使用

Stop TheWorld说明

JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿；会带给用户不良的体验；从JDK1.3到现在，从Serial收集器-》Parallel收集器-》CMS-》G1，用户线程停顿时间不断缩短，但仍然无法完全消除；

parNew收集器

ParNew垃圾收集器是Serial收集器的多线程版本。新生代收集器
其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server，模式下的虚拟机中首选的新生代收集器。

特点

• 除了多线程外，其余的行为、特点和Serial收集器一样；
• Serial收集器可用控制参数、收集算法、Stop The World、内存分配规则、回收策略等；
• 并行收集（非并发）
• 能与CMS收集器配合工作
• 作用于新生代

应用场景

• 在Server模式下，ParNew收集器是一个非常重要的收集器，因为除Serial外，目前只有它能与CMS收集器配合工作；如果老年代使用CMS那么新生代只能在serial和parNew中选一个
• 在单个CPU环境中，不会比Serail收集器有更好的效果，因为存在线程交互开销。

图文说明

parallel scavenge收集器

parallel scavenge收集器一个并行收集器，看上去和parNew都一样，只是它的关注点与其他收集器不一样。CMS收集器关注的是尽可能缩短垃圾收集时用户线程的停顿时间。而paralle scavenge关注的是可控制的吞吐量。
吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）
用于精确吞吐量的两个参数：1.控制最大垃圾收集停顿时间参数 2.直接设置吞吐量大小的参数
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。高吞吐量则可以高校的利用CUP时间，尽快完成程序的运算任务，适合后台运算而不需要太多交互的任务。
CMS适用于IO密集型的程序。parallel scavenge适用与CUP密集型的程序。

特点

• 可以控制程序吞吐量
• 并行收集（非并发）
• 作用于新生代

应用场景

• 吞吐量优先的场景

CMS收集器

并发标记清理收集器(CMS收集器)的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如web应用。在我们看一下有关JVM的参数之前,让我们简要回顾CMS收集器的操作和使用它时可能出现的主要挑战。
就像parallel scavenge收集器,CMS收集器处理老年代的对象,然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点(短暂的)停顿时间。GC与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS收集器的GC周期被分为了好几个连续的阶段。

触发条件

• 如果没有设置-XX:+UseCMSInitiatingOccupancyOnly，虚拟机会根据收集的数据决定是否触发（建议带上这个参数）。
• 老年代使用率达到阈值 CMSInitiatingOccupancyFraction，默认92%，前提是配置了第一个参数。
• 永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，默认92%，前提是开启 CMSClassUnloadingEnabled并且配置了第一个参数。
• 新生代的晋升担保失败。

CMS收集器的过程

• 初始标记：为了收集应用程序的对象引用需要暂停应用程序线程，该阶段完成后，应用程序线程再次启动。
• 并发标记：从第一阶段收集到的对象引用开始，遍历所有其他的对象引用。
• 重新标记：由于第三阶段是并发的，对象引用可能会发生进一步改变。因此，应用程序线程会再一次被暂停以更新这些变化，并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要，因为必须避免收集到仍被引用的对象。
• 并发清理：所有不再被应用的对象将从堆里清除掉。
• 并发重置：收集器做一些收尾的工作，以便下一次GC周期能有一个干净的状态。

CMS收集器带来的问题

• 空间碎片，CMS基础算法是标记-清除算法，所以标记-清除算法有的缺点CMS肯定有。
• 对象分配率高

空间碎片。 CMS收集器并没有任何碎片整理的机制。因此，应用程序有可能出现这样的情形，即使总的堆大小远没有耗尽，但却不能分配对象——仅仅是因为没有足够连续的空间完全容纳对象。当这种事发生后，并发算法不会帮上任何忙，因此，万不得已JVM会触发Full GC。回想一下，Full GC 将运行吞吐量收集器的算法，从而解决碎片问题——但却暂停了应用程序线程。因此尽管CMS收集器带来完全的并发性，但仍然有可能发生长时间的“stop-the-world”的风险。这是“设计”，而不能避免的——我们只能通过调优收集器来它的可能性。想要100%保证避免”stop-the-world”，对于交互式应用是有问题的。

对象分配率高。如果获取对象实例的频率高于收集器清除堆里死对象的频率，并发算法将再次失败。从某种程度上说，老年代将没有足够的可用空间来容纳一个从年轻代提升过来的对象。这种情况被称为“并发模式失败”，并且JVM会执行堆碎片整理：触发Full GC。

G1收集器

G1参考连接：https://tech.meituan.com/2016/09/23/g1.html
G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求
G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色：

• G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。
• G1的Stop The World(STW)更可控
• G1在停顿时间上添加了预测机制
• 用户可以指定期望停顿时间。