jvm垃圾收集器

JVM垃圾收集器

​ 7种不同的分代的收集器，如果两个收集器之间存在连线，说明它们可以搭配使用。分为Young generation（新生代收集器）和Tenured generation（老年代收集器）。

​ 明确一个观点：虽然我们是在对每个收集器进行比较，但并非为了挑选出一个最好的收集器。因为到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最适合的收集器。这点不需要多家解释就能证明：如果有一种放之四海而皆准、任何场景下都是用的完美收集器存在，那HotSpot虚拟机就没必要实现那么多不同的收集器了。

1. Serial 收集器

   ​ 单线程收集器，只使用一个CPU或一条收集线程去完成垃圾收集工作，在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。俗称：“Stop The World”。实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对于很多应用来说都是难以接受的。
   
   ​ 特点：简单而高效（与其他收集器的单线程比）

   ​ 在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不是很大，收集几十兆甚至一两百兆的新生代，停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。因此，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

2. ParNew 收集器

   ​ 是Serial收集器的多线程版本。除了使用多线程进行垃圾收集之外，其余的行为包括其所有控制参数（例如：-XX:SruvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略都与Serial收集器完全一样。在实现上，这两者也共用了相当多的代码。
   
   ​ 最重要的一点是，目前，除了Serial收集器外，只有它能够与CMS收集器配合工作。这个CMS收集器是一个具有跨时代意义的垃圾收集器，是第一款真正意义上的并发收集器。第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

   需明确：并行与并发 两种收集器

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

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

3. Parallel Scavenge 收集器

   ​ Parallel Scavenge收集器是新生代收集器，其也是使用复制算法的并行的多线程收集器，看上去跟ParNew收集器差不多。但Parallel Scavenge收集器的特点是它的关注点和其他的收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge 收集器的目的则是达到一个可控制的吞吐量。

   吞吐量：是CPU用于运行用户代码的时间与CPU中消耗时间的比值，即

   ​ 吞吐量 = 运行用户代码时间 / （运行用户代码时间+垃圾收集时间）

   虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那么吞吐量就是99%。

   ​ Parallel Scavenge收集器就是这种称为“吞吐量优先”的收集器，其提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis 以及直接设置吞吐量大小的 -XX:GCTimeRatio 。

   ①MaxGCPauseMillis 是一个大于0的毫秒数，收集器将尽可能的保证内存回收花费的时间不超过设定值。GC停顿时间的缩短是以牺牲吞吐量和新生代空间来换取的，例如 每次收集300MB肯定比收集500MB快，这就导致垃圾收集发生的更频繁了，原来10秒收集一次，每次停顿100毫秒，现在变成了每5秒收集一次，每次停顿70毫秒。停顿的时间确实是在下降，但吞吐量也在跟着下降。

   ②GCTimeRatio 是一个0-100以内的整数，也就是垃圾收集时间占总时间的比率，也就相当于是吞吐量的倒数。如果把参数设置为19，那允许的最大GC时间就占总时间的5%（即1/(1+19)）,默认是99，就是允许最大1%（即1/(1+99)）的垃圾收集时间。

   除了这两个参数，还有一个参数 -XX:+UseAdaptiveSizePolicy 值得关注。

   ③UseAdaptiveSizePolicy是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调正这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。

4. Serial Old 收集器

   Serial Old是Serial 收集器的老年代版本，它同样是单线程的收集器，试用“标记-整理算法”。这个收集器的主要意义是在于给Client模式下的虚拟机试用。而如果在Server模式下，那主要还有两大用途：一是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配试用，另一种用途是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

5. Parallel Old 收集器

   ​ Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，选用新生代的Parallel Scavenge收集器后，老年代收集器除了搭配Serial Old收集器外别无选择（Parallel Scavenge收集器无法与CMS收集器配合工作，而由于Serial Old收集器在服务端应用性能上的“拖累”）。因此，在 Parallel Old 收集器出现之后，“吞吐量优先”收集器终于有了名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

6. CMS 收集器

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

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

   • 初始标记 --标记 GC Roots 能直接关联到的对象，速度很快

   • 并发标记 --即进行GC Roots Tracing 的过程

   • 重新标记 --为了修正并发标记期间因用户程序继续运作而导致标记产生的变动

   • 并发清除

     ​ 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收时与用户线程一起并发执行的。

7. G1 收集器

   ​ G1收集器时当今收集器技术发展的最前沿成果之一，与其他GC收集器相比，具备以下特点：

   • 并行与并发：充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短 Stop-The-World 停顿的时间，部分其他收集器原本需要停顿Java线程执行GC动作，而G1收集器任然可以让Java程序继续执行。
   • 分代收集：它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。
   • 空间整合：G1从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为违法找到连续内存空间而提前触发下次GC。
   • 可预测的停顿：这是G1相对于CMS的又一大优势，减低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

   ​ 其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

   ​ G1之所以能建立可预测的停顿时间模型，是因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

   ​ G1收集器大致可分为如下步骤：

   • 初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

   • 并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

   • 最终标记：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

   • 筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YfwqNmtt-1642492013918)(垃圾收集器.assets/image-20220118153132979.png)]

• 筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）