转载

JVM之GC算法的实现(垃圾回收器)

上一节：《JVM之GC算法》知道GC算法的理论基础，我们来看看具体的实现。只有落地的理论，才是真理。

一、JVM垃圾回收器的结构

JVM虚拟机规范对垃圾收集器应该如何实现没有规定，因为没有最好的垃圾收集器，只有最适合的场景。

JVM之GC算法的实现(垃圾回收器)

图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

7种：serial收集器、parnew收集器、parallel scavenge收集器、serial old 收集器、parallel old收集器、cms收集器、g1收集器(整堆收集器)、

串行收集：单垃圾收集线程，进行收集工作，用户进程需要等待

并行收集：工作原理与串行一样，只是在收集垃圾时是多条线程同时进行，收集的效率在一般情况下自然高于单线程。

并发收集：指用户线程与垃圾收集线程同时工作（并发：同一时间间隔）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

吞吐量：吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值(吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）)

1、Serial收集器

Serial(串行)收集器：最基本，最古老的收集器，只有一个线程进行垃圾收集器的工作，并且在进行垃圾收集工作时需要暂停其他工作线程(stop the word),直到他工作结束；

Serial收集器简单高效，工作时没有线程交互的开销，所以可以获得很高的单线程收集效率，对于运行在Client模式下的虚拟机来说很适合。

"-XX:+UseSerialGC"：添加该参数来显式的使用Serial垃圾收集器。

JVM之GC算法的实现(垃圾回收器)

2、Serial Old收集器

Serial Old收集器是Seria收集器的老年代版本，他同样是一个单线程收集器，使用" 标记-整理" 算法。

Serial Old收集器主要用于Client模式下的虚拟机使用。

Server模式下的两大用途：

在JDK1.5及之前的版本与Parallel Scavenge收集器搭配使用；
作为CMS收集器的后备方案，在并发收集发生Conturrent Mode Failure时使用。

3、ParNew 收集器

ParNew(并行)收集器就是Serial收集器的多线程版本，除了在收集垃圾时是启用多线程并行执行，其他行为(控制参数、收集算法、回收策略/Stop The Word、对象分配规则)完全一样

JVM之GC算法的实现(垃圾回收器)

应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

"-XX:+UseConcMarkSweepGC"：指定使用CMS后，会默认使用ParNew作为新生代收集器。

"-XX:+UseParNewGC"：强制指定使用ParNew。

"-XX:ParallelGCThreads"：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同。

4、Parallel Scavenge收集器Parallel Scavenge收集器类似于 ParNew 收集器， Parallel Scavenge收集器更加关注吞吐量(高效的CPU利用率)。CMS等垃圾收集器关注更多的是用户线程的停顿时间(提搞用户体验)；Parallel Scavenge 收集器提供很多参数供我们找到最合适的停顿时间或者最大吞吐量。JDK1.8 默认的方式；

Parallel Scavenge收集器提供了两个参数来用于精确控制吞吐量，一是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数，二是控制吞吐量大小的 -XX：GCTimeRatio参数；

“ -XX：MaxGCPauseMillis” 参数允许的值是一个大于0的毫秒数，收集器将尽可能的保证内存垃圾回收花费的时间不超过设定的值（但是，并不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然GC停顿时间下来了，但是吞吐量也下来了）。
“ -XX：GCTimeRatio”参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
“-XX：UseAdaptiveSizePolicy”参数是一个开发，如果这个参数打开之后，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的比例、老年大大小等细节参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略。

JVM之GC算法的实现(垃圾回收器)

应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

5、Paraller Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

在JDK1.6中才出现。

6、CMS（Conturrent Mark Sweep）收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于“标记-清除”算法实现，它的整个运行过程可以分为：

初始标记：标记一下GC Roots能直接关联到的对象，这个过程速度很快，但是会暂停其他用户线程(Stop the word)
并发标记：进行GCRoots Tracing的过程，同时开启GC和用户线程，用一个闭包的结构去记录可达对象，但是在这个阶段结束，该闭包不能保证其包含当前所有的可达对象。因为用户进程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法会跟踪记录这些发生引用更新的地方。
重新标记：修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，该阶段会GC停顿，停顿时间比初始标记时间稍长，单远比并发标记时间短。
并发清除：开启用户线程，同事GC线程清除死亡的对象

CMS收集器运行的整个过程中，最耗费时间的是并发标记和并发清除，GC收集器线程和用户线程是一起工作的，所以总体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

JVM之GC算法的实现(垃圾回收器)

优点：并发收集、低停顿。

缺点：

1、CMS收集器对CPU资源非常敏感。虽然在两个并发阶段不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是（CPU数量+3）/4。
2、：CMS收集器无法处理浮动垃圾，可能出现“Conturrent Mode Failure”失败而导致另一次Full GC产生。由于CMS并发清除阶段用户线程还在运行，伴随着程序还在产生新的垃圾，这一部分垃圾出现在标记之后，CMS无法在当次收集中处理掉它们，只能留到下次再清理，这一部分垃圾称为“浮动垃圾”。也正是由于在垃圾收集阶段用户线程还在运行，那么也就需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等待老年代填满之后再进行收集，需要预留一部分空间给并发收集时用户程序使用。可以通过“-XX：CMSInitiatingOccupancyFraction”参数设置老年代内存使用达到多少时启动收集。
3、：由于CMS收集器是一个基于“标记-清除”算法的收集器，那么意味着收集结束会产生大量碎片，有时候往往还有很多内存未使用，但是没有一块连续的空间来分配这个大对象，导致不得不提前触发一次Full GC。CMS收集器提供了一个“-XX：UseCMSCompactAtFullCollection”参数（默认是开启的）用于在CMS收集器顶不住要FullGC时开启内存碎片整理（内存碎片整理意味着无法并发执行不得不停顿用户线程）。参数“-XX：CMSFullGCsBeforeCompaction”来设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值是0，意味着每次进入Full GC时都进行碎片整理）。