JVM（四）常见的七种垃圾回收器

孤独的红心
886 阅读13分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第13天，点击查看活动详情

上一篇文章垃圾回收器介绍了垃圾回收器的分类、垃圾回收器性能评估指标以及当前常见的七种垃圾回收器的组合关系，今天逐一回顾一下这七种垃圾回收器，思考每种垃圾回收器的特点，在什么情况下选择哪种垃圾回收器，为什么要设计这么多垃圾回收器，为了提高Java程序运行性能，新的垃圾回收器应该如何设计。

未命名文件 (20).png

Serial回收器-串行回收器

Serial系列回收器有两种，一个负责年轻代的垃圾回收，另一个Serial Old负责老年代的垃圾回收。Serial回收器主要采用复制算法、串行回收和“Stop the World”机制，Serial Old和Serial类似，不过在内存回收时使用的是标记-压缩算法。

未命名文件 (22).png
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(stop The wor1d)。

SerialSerial Old
复制算法标记压缩
年轻代老年代
适合 Client模式Server模式

Serial Old在server模式下主要有两个用途：

  • 与新生代的Parallel Scavenge配合使用
  • 作为CMS收集器的后背垃圾回收方案

如何使用Serial回收器
在HotSpot虚拟机中，使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。 等价于新生代用serial GC，且老年代用serial old GC

总结： Serial回收器与其他回收器的单线程相比简单而高效，对于限定单个CPU的环境来说，Serial回收器由于没有线程切换的开销，可以获得二最高的单线程收集效率。适合用户的桌面应用和Client模式场景。对于交互较强的应用，比如Javaweb应用，Serial回收器是无法满足需求的。

ParNew回收器-并行回收

首先来解释一下ParNew名称的意义方便记忆，Par是Parallel的缩写，New:只能处理的是新生代。从名字就可以看出ParNew回收器的特点：并行和新生代。如果说serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是serial收集器的多线程版本。

未命名文件 (23).png

由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比serial收集器更高效?

  • ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU、 多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。
  • 但是在单个CPU的环境下，ParNew收集器不比serial 收集器更高 效。虽然serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。

如何使用ParNew

  • 在程序中，开发人员可以通过选项"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。
  • 一XX: ParallelGCThreads 限制线程数量，默认开启和cPu数据相同的线程数。

总结：

  • 对于新生代，回收次数频繁，使用并行方式高效。
  • 对于老年代，回收次数少，使用串行方式节省资源。(CPU并行需要切换线程，串行可以省去切换线程的资源)
  • ParNew一般作为新生代垃圾回收器和其他老年代垃圾回收器（Serial、CMS）配合使用

Parallel Scavenge回收器-吞吐量优先

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World”机制。但Parallel Scavenge和ParNew又有一些不同：（1）Parallel Scavenge以达到一个可控制的吞吐量为目标；（2）采用自适应调节策略。

未命名文件 (24).png 自适应调节策略： 在这种模式下，年轻代的大小、Eden和survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间(MaxGCPauseMills) ，让虚拟机自己完成调优工作。

应用场景
高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

在程序吞吐量优先的应用场景中，Parallel Scavenge收集器和Parallel old 收集器的组合，在server模式下的内存回收性能很不错。

Parallel Scavenge使用

  • -XX:+UseParallelGC手动指定年轻代使用Parallel并行收集器执行内存回收任务。

  • -XX:+UseParalle1OldGC手动指定老年代都是使用并行回收收集器

    • 分别适用于新生代和老年代。默认jdk8是开启的。
    • 上面两个参数，默认开启一个，另一个也会被开启。（互相激活)

  • -XX: ParallelGCThreads设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。

    • 在默认情况下，当CPU数量小于8个，ParallelGcThreads的值等于CPU数量。
    • 当CPU数量大于8个，ParallelGCThreads的值等于3+「5*CPU Count1 /8]

  • -XX:+UseAdaptivesizePolicy设置Parallel scavenge收集器具有自适应调节策略

  • -XX: MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间)。单位是毫秒。

    • 为了尽可能地把停顿时阅控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。
    • 对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。
    • 该参数使用需谨慎。

  • -XX:GCTimeRatio垃圾收集时间占总时间的比例(1 / (N + 1) ),相当于是吞吐量的倒数 。用于衡量吞吐量的大小。

    • 取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%。
    • 与前一个-xX:MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。

CMS回收器-低延迟

在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS (concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求。

未命名文件 (25).png
不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在新生代收集器Parallel scavenge配合工作，所以在3DK 1.5中使用CMS收集老年代的时候，新生代只能选择ParNew或者serial收集器中的一个。 在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC。

CMS的垃圾收集算法采用标记-清除算法，并且也会"stop-the-world”。

下面看看CMS的工作原理
CMS整个过程比之前的收集器要复杂,整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。

未命名文件 (26).png

  • 初始标记（Initial-Mark)阶段：在这个阶段中，程序中所有的工作线程都将会因为“Stop-the-world”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GC Roots能直接关联的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的速度非常快
  • 并发标记（Concurrent-Mark)阶段:从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
  • 重新标记（Remark）阶段:由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
  • 并发清除(Concurrent-Sweep）阶段:此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

尽管CMS收集器采用的是并发回收（非独占式），但是在其初始化标记和再次标记这两个阶段中仍然需要执行“Stop-the-world”机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要“Stop-the-wor1d”，只是尽可能地缩短暂停时间。由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。

另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案:临时启用Serial old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

CMS具有低延迟和并发收集的优点，但也存在一些弊端：

  1. 会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。
  2. CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
  3. CMs收集器无法处理浮动垃圾。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行C时释放这些之前未被回收的内存空间。
  4. 可能出现“Concurrent Mode railure"失败而导致另一次 Full GC的产生。

有人会觉得既然Mark Sweep会造成内存碎片,那么为什么不把算法换成Mark Compact呢?
答案其实很简答，因为当并发清除的时候，用compact整理内存的话，原来的用户线程使用的内存还怎么用呢?要保证用户线程能继续执行，前提的它运行的资源不受影响嘛。Mark compact更适合“stop the world”这种场景下使用。

CMS使用

  • -XX:UseConcMarkSweepGC手动指定使用CMS收集器执行内存回收任务。
    • 开启该参数后会自动将-XX:+UseParNewGc打开。即:ParNew (Young区用)+CMS(Old区用)+serial old的组合。
  • -XX:CMSInitiatingOccupanyFraction设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。
    • JDK5及以前版本的默认值为68,即当老年代的空间使用率达到68%时，会执行一次CMs回收。JDK6及以上版本默认值为92%
    • 如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阀值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数。
  • -XX:+UseCMSCompactAtFullCollection用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。
  • -XX:CMSFullGCsBeforeCompaction设置在执行多少次Full Gc后对内存空间进行压缩整理。
  • -XX: ParallelCMSThreads设置CMS的线程数量。
    • CMS 默认启动的线程数是（ParallelGcThreads+3)/ 4，ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。

如何选择垃圾回收器

  • 如果你想要最小化地使用内存和并行开销，可以选serial GC
  • 如果你想要最大化应用程序的吞吐量，可以选Parallel GC
  • 如果你想要最小化cc的中断或停顿时间，可以选CMS GC
avatar
文章
阅读
粉丝