这一篇就来聊一聊GC，不垃聊聊我们的圾心垃圾回收器，我们知道Java的点数垃圾回收机制与C++的有所不同，作为Java程序员不用在程序中自己释放内存，不垃自己去管理内存，圾心对于内存使用似乎是点数“肆无忌惮”一样。

然而，不垃这背后一切的圾心原因就是JVM的GC已经帮我们做了这些事，能够帮我们自动管理这些事，点数当内存紧张的不垃时候，就会触发垃圾回收机制，圾心腾出足够的点数空间来供我们程序使用。

但是不垃，JVM的圾心GC也不是万能的，也有翻车的点数时候，比如碰到过内存泄露的时候，就会导致GC的内存回收的效率低下，源码库甚至出现OOM的异常。

作为Java程序员，我们要做的就是要保证GC正常工作，基于这种情况下对于GC的工作的原理和GC的使用的场景就得有所了解。

下面就开始我们的正文，这里我画了一个介绍这篇文章主要内容的思维导图：

首先先来聊聊哪些对象应该被GC，JVM是怎么判断一个对象是否存活的呢?

判断对象存活

想要判断对象是否存活，有两种方法：

引用计数法 可达性分析算法

引用计数法

第一个引用计数法实现简单，效率高。它的原理就是在对象内部维护一个计数器，当有地方引用它的时候，计数器+1，当有地方不再引用它的时候，计数器-1。

就这样，当计数器为零的站群服务器时候，表示没有地方引用它，那么这个对应就应该要被GC回收了。

但是这种算法却很少被Java虚拟机使用，主要原因是它有漏洞：无法解决循环引用的问题：

可达性分析算法

第二种就是可达性分析算法，它是以一组GCRoots为起点，根据引用链的关系向下搜索，若是某个对象与GCRoot之间没有任何的引用链，则这个对象是不可达的，也是将来会被回收掉的。

这种算法被引用在主流的Java虚拟机中，比如HotSpot，那哪些对象可以作为GCRoots呢?主要有以下的对象可以作为GCRoots：

虚拟栈中引用的对象。 方法区中的静态变量。 方法区中的常量。 以及本地方法栈JNI引用的源码下载对象(这个可以忽略，我们几乎没有接触)。

以上比较常见的就是方法区中的静态变量和常量的引用对象，知道了怎么判断对象是否存活，下面就是用可达性分析算法，用到具体的垃圾回收算法上。

垃圾回收算法

对于垃圾回收算法，我这里就不做过于详细的介绍，就简单介绍一下，因为之前已经写过一篇比较详细的文章了，大家可以参考一下：还在学JVM?我都帮你总结好了(附脑图)

常见的垃圾回收算法就这三种：

标记-清除 复制算法 标记-整理(压缩算法)

我们知道年轻代基本都是朝生夕死，所以都是使用复制算法，复制的成本低，基于这种分代模型理论，也就出现了后面垃圾回收器的Eden区、From Survivor区、To Survivor空间(默认8:1:1)。

新生代中每次都只有Eden和其中的一个S区可用，当Eden区满了，就会将存活的对象复制到其中的一个S区中，若是S区也满了，此区域不满足晋升条件的对象就会被复制到到另一个S区中。就这样对象每经历一次Minor GC年龄就会+1，当达到晋升年龄的阈值，对象还没被垃圾回收掉，就会被放入;老年代。

而老年代使用的是标记-清除或者标记-整理，对于标记-清除我们知道它最大的缺点就是会产生内存碎片，但是他也有自己的好处(相比标记-整理)，就是不用移动对象，所以效率相比标记-整理要高。

而标记-整理完整的过程应该是标记-整理-清除三个步骤，需要将存活的对象向一边移动，然后清理掉不可达的对象，所以它的效率也会比较低，尤其是老年代这种区域，有大量的对象存活，那么对于移动对象所耗费的性能也是可观的。

还有一点比较重要的是：新生对象的内存分配的角度。这个是很多技术博文都忽略的一点，这一点也是比较重要的，在《深入JVM虚拟机 第三版》中也有特别强调这一点。

从内存分配的角度来看：对于标记-整理和复制算法，都是整理的规整空间，所以他们俩对于新产生的对象进行分配内存的时候，是比较简单高效的，特别是对于一些大对象的分配以及连续内存对象的分配(数组)。

标记-整理和复制算法只需要内存地址指针移动与对象一样大小的位置，便可完成内存分配，这样高效简单。

而对于标记-清除法，因为产生了内存碎片，所以它必须要记住哪些地方是可用的，哪些地方是不可用的，这样内存分配的效率就会低很多。

知道了具体的垃圾回收算法，下面就来聊聊具体的垃圾回收器。

垃圾回收器

根据分离代理模型，对于不同的区域设计出了不同的垃圾回收器，对于经典的垃圾回收器主要有这么几种：

Serial(新生代) SerialOld(老年代) PS(新生代) PO(老年代) ParNew(新生代) CMS(老年代) G1

对于以上几种的垃圾回收器，可以选择不同的老年代和年轻代进行搭配使用，主要有以下的搭配方式：

Serial

Serial系列的垃圾回收器，现在也基本没人用了，它的使用原理就是使用单线程来进行垃圾回收，所以STW的时间也会比较长，实现简单。老年代的SerialOld使用的是标记-整理的算法来回收垃圾。

来源于深入JVM虚拟机

在若是你的服务器还处在单核时代，内存只有那么几十M到百来M，可能Serial是最优的搭配选择。

对于Serial的相关JVM参数有：-XX:+UseSerialGC(使用Serial垃圾回收器)。

Parallel

当发展到多线程时代，PS和PO的搭配就出现了，PS和PO相对于Serial比较来说，就是垃圾回收的时候是使用的是多线程，其它的一样，包括使用的垃圾回收算法也一样，所以在多核时代，它相比Serial STW的时间变得更短了：

这里涉及到一个吞吐量的概念：吞吐量 = 用户应用程序运行的时间 / (应用程序运行的时间 + 垃圾回收的时间)，因为PS+PO的搭配是追求吞吐量的垃圾回收器。

因此PS+PO的组合比较适用于后台快速完成计算任务，不需要太多的与用户交互的场景。

与PS+PO有关的JVM参数如下所示：

-XX: +UseParallelGC：开启ParallelGC。 -XX: +UseParallelOldGC：开启老年代的ParallelGC，和上面的任意开启一个就行。 -XX: ParallelGCThreads：指定线程数。 -XX：MaxGCPauseMillis：控制最大垃圾收集停顿时间(毫秒数) -XX：GCTimeRatio：直接设置吞吐量大小(大于0小于100的整数) -XX：+UseAdaptiveSizePolicy：当这个参数被激活后，就不需要制定新生代的大小(-Xmn)、Eden和S区的比例(-XX：SurvivorRatio)、晋升老年代对象的大小(-XX：PretenureSizeThreshold)等参数，虚拟机会自己动态的调整。

PS和PO是Java 8默认的垃圾回收器，不知道各位读者的Java的版本是多少，已经使用Java 8好久了。

ParNew

ParNew实际上和Parallel的实现原理基本相同，唯一不同的是它可以和CMS搭配使用，而PS是没办法与CMS搭配使用，这也使得ParNew火起来，当JVM中设置了使用CMS作为老年代的回收器的时候，新生代的垃圾回收器默认就是ParNew。

CMS

CMS可以说是跨时代的一款垃圾回收器，它实现了垃圾回收与用户线程并发进行，在它是一种以获取最短垃圾停顿时间为目的的垃圾回收器。

特别适用于用户频繁交互的场景，它的实现过程分为以下四个阶段：

初始标记 并发标记 重新标记 并发清理

其中初始标记和重新标记是需要STW的，而并发标记和并发清理垃圾回收线程与用户线程并发执行。

初始标记阶段仅仅是标记GC Root直接关联的对象，并不会遍历整个对象图，所以速度很快。

并发标记阶段就是从GC Root开始遍历整个对象图的过程，这个过程是四个阶段最耗时的过程，因此此阶段也是与用户线程并发执行的，不需要停顿用户线程。

重新标记阶段是修正在并发标记阶段因用户线程运行产生一些对象的引用关系变动的标记记录，因为在并发阶段用户线程与垃圾回收线程是并发执行的，那么就有可能之前已经标记的，它的引用关系又被改变了，这需要在这个阶段重新修正。

并发清理因为不用移动用户对象，因此可以与用户线程一起并发执行，最后清理掉不可达的对象。

四个阶段中其中最复杂的就是第三阶段并发标记，其中涉及到的一个重要概念就是三色标记法，第三阶段在标记的过程有可能对对象产生漏标或者多标的现象，那CMS又是怎么来解决这两个问题的呢?

我们先来详细了解一下三色标记法。三色标记法中将对象分为白色、灰色、黑色的过程。

白色：白色是对象默认的颜色，从GC Root开始扫描，如果不可达的对象的就是白色，在并发清理阶段就会被清理掉。 灰色：灰色表示当前对象已经被扫描，但是当前对象所依赖的其他对象还没有被扫描。 黑色：黑色表示当前对象和它所依赖的对象都已经被扫描过。

那它又是怎么产生多标和漏标的呢?下面来画图看看：

开始有三个对象，分别是对象1和对象2以及对象3，三个对象与GC Root之间都存在引用链，当开始进行标记，就会从GC Root开始扫描。

当扫描了对象1和对象2的时候，因为对象2没有再依赖的引用，所以它会变成黑色，而对象1还引用着对象3，并且对象3还没有扫描，所以对象1变成灰色。

若是，此时用户线程将对象3与对象1之间的引用关系改变了，变成了对象2与对象3之间有引用关系，因为对象2已经扫描完了，对象3还没扫描，此时应该是对象2是灰色的状态，并且对象3是白色的状态，对象3就会被回收掉，这就出现了漏标的情况。

多标的情况就是当对象1和对象3之间开始有引用链，并且都已经标记为黑色，此时用户线程又把对象3设置为null，那么此时按理来说对象3应该被回收的，但是因为是黑色并不会被回收掉，所以出现了多标，多标的情况可以在下次垃圾回收的时候，进行重新标记，被重新回收，所以多标并不会是GC回收的过程出现bug。

而漏标就需要解决了，不然GC回收就会出现bug，对于漏标CMS给出的解决方案是增量更新的方法。它的原理就是假如对象3的引用变成了对象2，那么对象2就会变成灰色，并且对象2会被集合里面，在重新标记的阶段以对象2为根节点向下扫描。

这样CMS就解决漏标的问题，并且实现了整个GC Root对象图的时候，能够与用户线程并发执行，大大减少了STW的时间。

那为什么CMS又选择标记-清除算法呢?因为假如选择标记-整理算法，在并发清理阶段因为要进行整理，涉及对象的移动，此时就不能与用户线程一起并发操作，这样清理阶段就必须STW，就违背了CMS设计初衷：获取最短回收停顿时间。

与CMS有关的JVM参数如下所示：

-XX：+UseConcMarkSweepGC：使用CMS垃圾收集器(当设置这个参数后，年轻代默认会开启ParNew)。 -XX:+UseCMSCompactAtFullCollection：用于在CMS收集器不得不进行FullGC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，清理阶段是无法并发的，此参数从JDK9开始废弃。 -XX：CMSFullGCsBefore-Compaction：多少次FullGC之后压缩一次，默认值为0，表示每次进入FullGC时都进行碎片整理，此参数从JDK9开始废弃。 -XX:CMSInitiatingOccupancyFraction：当老年代使用达到该比例时会触发FullGC，默认是92。 -XX:+UseCMSInitiatingOccupancyOnly：这个参数搭配上面那个用，表示是不是要一直使用上面的比例触发FullGC，如果设置则只会在第一次FullGC的时候使用-XX:CMSInitiatingOccupancyFraction的值，之后会进行自动调整。 -XX:+CMSScavengeBeforeRemark：在FullGC前启动一次MinorGC，目的在于减少老年代对年轻代的引用，降低CMSGC的标记阶段时的开销，一般CMS的GC耗时80%都在标记阶段。 -XX:+CMSParallellnitialMarkEnabled：默认情况下初始标记是单线程的，这个参数可以让他多线程执行，可以减少STW。 -XX:+CMSParallelRemarkEnabled：使用多线程进行重新标记，目的也是为了减少STW。

CMS的出现是有着非常重要的意义，它为后面更加智能的垃圾回收器G1、ZGC的出现奠定了基础，首次实现：用户线程与垃圾回收线程并发执行，但是慢慢的CMS也退出了舞台。

你会发现关于CMS的很多相关的JVM参数在jdk9已经废弃，并且在jdk9，默认的垃圾回收器已经不再是PS+PO了，已经变成了G1，说明JVM设计团队认为G1已经可以取代以前的垃圾回收器了(我还停留在jdk8，手动狗头)，我相信应该还有很多人在jdk8吧，哈哈哈。

G1

最后聊得就是G1了，G1因为它的优势也成为了jdk9的默认垃圾回收器。它与其他的回收器不同的是，它将整个堆划分为很多个Region，每个Region的大小大概在1M-32M之间。

它不在像以前的垃圾回收器一样将整个堆划分为年轻代和老年代，它的衡量标准是以哪块Region回收的利益最大，这就是G1的MixedGC模式。

G1的阶段过程和CMS有异曲同工之妙，也是分为四个阶段：

初始标记 并发标记 最终标记 筛选回收

初始标记和CMS一样，需要STW，只是标记GC Roots直接关联的对象，时间会非常的短。

并发标记也是与用户线程一起并发执行，需要从GC Root开始遍历整个对象图，也是消耗时间最长的阶段。

最终标记阶段用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录，也就是并发标记阶段引用关系重新改变的对象。

最后就是回收阶段，因为G1使用的是标记-整理算法，所以涉及到对象的移动，所以这个阶段是需要STW的，必须暂停用户线程，由多条线程来执行垃圾回收。

最后来聊一聊G1实现的一些小细节，一个是在并发标记阶段，它是怎么解决新对象内存分配的问题?另外一个最重要的细节就是它是怎么建立起可预估的停顿时间模型?在G1和CMS之间如何做选择呢?

先来看看第一个问题，在并发标记阶段用户线程也是在执行的，在执行就会产生新的对象，G1是为每一个Region设计了两个名为TAMS(TopatMarkStart)的指针。

并且把Region中的一部分空间划分出来用于新对象的内存分配，在并发回收时新分配的对象地址都必须要在这两个指针位置以上。

然后第二个细节就是G1在垃圾回收的过程中会记录每一个Region的回收耗时，花费的成本，并且根据多次计算出平均值，这样能够预估每一个Region的垃圾耗时，然后根据程序中设定的最短垃圾回收时间，估算回收哪一些Region是利益最大的。

那么在G1和CMS之间是如何进行选择的呢?对于小内存的(1G-4G)CMS的可能会优于G1，而对于大内存的(6G-8G)的可能G1就会显现出自己的优势。

最后与G1有关的JVM参数如下：

-XX：G1HeapRegionSize：设置每个Region的大小，取值范围为1MB～32MB。 -XX：MaxGCPauseMillis：设置垃圾收集器的停顿时间，默认值是200毫秒。

好了有关于垃圾器的就聊到这里，还有一个也是比较经典的就是ZGC，有兴趣的可以自行去了解一下，限于篇幅原因，这一片关于JVM的垃圾，我们就聊到这里，下一篇继续深入聊JVM，我是黎杜，我们下一期见。

本文转载自微信公众号「黎杜编程」，可以通过以下二维码关注。转载本文请联系黎杜编程小熊公众号。