Java垃圾收集器概述

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。现代的商用虚拟机的都是采用分代收集的，不同的区域用不同的收集器。常用的7种收集器如图所示。

Serial、ParNew、Parallel Scavenge用于新生代；
CMS、Serial Old、Parallel Old用于老年代。
并且他们相互之间以相对固定的组合使用（具体组合关系如上图）。G1是一个独立的收集器不依赖其他6种收集器。ZGC是目前JDK 11的实验收集器

概念解释

并行（Parallel）：指多条垃圾收集线之间程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序继续运行，而垃圾收集程序运行于另一个CPU上。
吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值

新生代收集器

Serial

Serial是单线程执行垃圾回收的。当需要执行垃圾回收时，程序会暂停一切手上的工作。这个过程是不可控制的，是虚拟机在后台自动发起和自动完成，然后单线程执行垃圾回收。因为新生代的特点是对象存活率低，所以收集算法用的是复制算法，把新生代存活对象复制到老年代，复制的内容不多,并且避免了线程切换的开销，从而简单高效。。

由于其简单高效，但是又又不可控制的暂停的时间，因此使用场景局限与在桌面应用中。

ParNew

ParNew同样用于新生代，是Serial的多线程版本，并且在参数、算法（同样是复制算法）上也完全和Serial相同。
Par是Parallel的缩写，但它的并行仅仅指的是收集多线程并行，并不是收集和原程序可以并行进行。ParNew也是需要暂停程序一切的工作，然后多线程执行垃圾回收。

因为是多线程执行，所以在多CPU下，ParNew效果通常会比Serial好。但如果是单CPU则会因为线程的切换，性能反而更差。

Parallel Scavenge

新生代的收集器，同样用的是复制算法，也是并行多线程收集。与ParNew最大的不同，它关注的是垃圾回收的吞吐量。

这里的吞吐量指的是 总时间与垃圾回收时间的比例。这个比例越高，证明垃圾回收占整个程序运行的比例越小。

Parallel Scavenge收集器提供两个参数控制垃圾回收的执行：

• -XX:MaxGCPauseMillis，最大垃圾回收停顿时间。这个参数的原理是空间换时间，收集器会控制新生代的区域大小，从而尽可能保证回收少于这个最大停顿时间。简单的说就是回收的区域越小，那么耗费的时间也越小。
  所以这个参数并不是设置得越小越好。设太小的话，新生代空间会太小，从而更频繁的触发GC。

• -XX:GCTimeRatio，垃圾回收时间与总时间占比。这个是吞吐量的倒数，原理和MaxGCPauseMillis相同。

因为Parallel Scavenge收集器关注的是吞吐量，所以当设置好以上参数的时候，同时不想设置各个区域大小（新生代，老年代等）。可以开启 -XX:UseAdaptiveSizePolicy 参数，让JVM监控收集的性能，动态调整这些区域大小参数。

另外值得注意的一点是，Parallel Scavenge收集器无法与CMS收集器配合使用，所以在JDK 1.6推出Parallel Old之前，如果新生代选择Parallel Scavenge收集器，老年代只有Serial Old收集器能与之配合使用。

老年代收集器

Serial Old

Serial Old 是 Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理（Mark-Compact）算法。

此收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：

• 在JDK1.5 以及之前版本（Parallel Old诞生以前）中与Parallel Scavenge收集器搭配使用。
• 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。前面已经提到过，这个收集器是在JDK 1.6中才开始提供的，在此之前，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old以外别无选择，所以在Parallel Old诞生以后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作流程与Parallel Scavenge相同

CMS

CMS，Concurrent Mark Sweep，同样是老年代的收集器。它关注的是垃圾回收最短的停顿时间（低停顿），在老年代并不频繁GC的场景下，是比较适用的。
命名中用的是concurrent，而不是parallel，说明这个收集器是有与工作执行并发的能力的。MS则说明算法用的是Mark Sweep算法。可以通过JVM启动参数：-XX:+UseConcMarkSweepGC来开启CMS。

CMS收集器工作的整个流程分为以下4个步骤：

• 初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
• 并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
• 重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这 个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop The World”。
• 并发清除（CMS concurrent sweep）：并发清除之前所标记的垃圾。其他用户线程仍可以工作，不需要停顿

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

优点

• CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，因此CMS收集器也被称为并发低停顿收集器（Concurrent Low Pause Collector）。

缺点

• Mark Sweep算法会导致内存碎片比较多
• CMS的并发能力依赖于CPU资源，所以在CPU数少和CPU资源紧张的情况下，性能较差
• 并发清除阶段，用户线程依然在运行，所以依然会产生新的垃圾，称为浮动垃圾，浮动垃圾并不会再本次GC中回收，而放到下次。所以GC不能等待内存耗尽的时候才进行GC，这样的话会导致并发清除的时候，用户线程可利用的空间不足。所以这里会浪费一些内存空间给用户线程预留。

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

总结

垃圾收集器比较重点和难点是CMS和G1，上一节知识粗略的讲述了CMS的工作流程，后面会单独对CMS和G1进行阐述。