[Java基础]-- Java GC 垃圾回收器的分类和优缺点

关于Java的垃圾回收器，一直是个头疼的问题，这里简要说明下分类和优缺点，供选择使用。

一、JVM GC 垃圾回收器类型

JVM的垃圾回收器大致分为六种类型：

1、串行：垃圾回收器 (Serial Garbage Collector)

(1)串行垃圾回收器在进行垃圾回收时，它会持有所有应用程序的线程，冻结所有应用程序线程，使用单个垃圾回收线程来进行垃圾回收工作。

串行垃圾回收器是为单线程环境而设计的，如果你的程序不需要多线程，启动串行垃圾回收。

(2)串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；新生代复制算法、老年代标记-压缩；垃圾收集的过程中会Stop The World（服务暂停）

使用方法：-XX:+UseSerialGC 串联收集

Ps：在jdk client模式，不指定VM参数，默认是串行垃圾回收器

2、串行：ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本。新生代并行，老年代串行；新生代复制算法、老年代标记-压缩
使用方法：-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制线程数量

3、并行：Parallel收集器
Parallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量；也可以通过参数控制GC的时间不大于多少毫秒或者比例；新生代复制算法、老年代标记-压缩
使用方法：-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行

4、并行：Parallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供
使用方法： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行

5、并发标记扫描CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

java官方介绍：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：
初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）

优点:并发收集、低停顿
缺点：产生大量空间碎片、并发阶段会降低吞吐量

注意：默认是并发标记收集器，当失败后，就会使用老年代的 Serial Old 垃圾回收器。

-XX:+UseConcMarkSweepGC 使用CMS收集器

-XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后，进行一次碎片整理
-XX:ParallelCMSThreads 设定CMS的线程数量（一般情况约等于可用CPU数量）

举例：

6、G1收集器
G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点：
(1). 空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
(2). 可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。
G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。和CMS类似，G1收集器收集老年代对象会有短暂停顿。
收集步骤：
1)、标记阶段，首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event)，并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)
2)、Root Region Scanning，程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。
3)、Concurrent Marking，在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。
4)、Remark, 再标记，会有短暂停顿(STW)。再标记阶段是用来收集并发标记阶段产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
5)、Copy/Clean up，多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。
6)、复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。唯一和串行垃圾回收器不同的是，并行垃圾回收器是使用多线程来进行垃圾回收工作的。

java8中，使用方法： -XX:+UseStringDeduplicatio默认：-XX:+UseG1GC

二、垃圾回收器的选用决定因素：

1、应用程序的场景
2、硬件的制约
3、吞吐量的需求

串行垃圾回收是最简单的也是效率最低的，如果只是控制台的单线程程序，简单任务，并且机器配置不高，推荐使用。

并行垃圾回收器是64bit server默认的垃圾回收器，一般我们工作和生产上默认不配置，都是并行垃圾回收。对于一般的不要求吞吐的应用，并且硬件资源不是太充足的情况下，并行垃圾回收器差不多能满足需求。

CMS垃圾回收器是对并行垃圾回收器的一个优化，它以CPU和系统资源为代价，换取GC的延迟。不会一GC就STW，而是根据情况STW。一定程度上是资源换取速度。

G1垃圾回收器是针对于大heap的垃圾回收器，如果heap分配的足够大，分的region的优先级回收策略会优先清理垃圾多的region.并且减少了内存空间碎片，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

三、配置

Option	Description
-XX:+UseSerialGC	Serial Garbage Collector 串行垃圾回收器
-XX:+UseParallelGC	Parallel Garbage Collector并行垃圾回收器
-XX:+UseConcMarkSweepGC	CMS Garbage Collector并发标记垃圾回收器
-XX:ParallelCMSThreads=	CMS Collector – number of threads to use 并发标记垃圾回收器使用的线程数，通常是cpu个数
-XX:+UseG1GC	G1 Gargbage Collector 使用G1垃圾回收器

GC Optimization Options

Option	Description
-Xms	Initial heap memory size 初始化heap大小 -Xms512M
-Xmx	Maximum heap memory size 设置最大的heap大小
-Xmn	Size of Young Generation 年轻代的大小
-XX:PermSize	Initial Permanent Generation size 初始化永久带的大小
-XX:MaxPermSize	Maximum Permanent Generation size 最大的永久带大小

Parallel GC 并行垃圾回收策略举例：

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC MaxGCPauseMillis=100 -XX:MaxGCPauseMillis=100

CMS GC 并发标记清楚垃圾回收策略举例：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k-XX:ParallelGCThreads=20  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

Eg：

java -Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC -jar java-application.jar-Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC -jar java-application.jar

更多详细配置，请参考：http://blog.sina.com.cn/s/blog_4080505a0101i6cr.html

四、查看垃圾回收器

我们知道jvm分client 和 server模式。

如果启动jvm不指定模式，jdk会根据当前的操作系统配置来启动不同模式的jvm。

默认64bit操作系统下都会是server模式的jvm。

java -XX: +PrintCommandLineFlags -version

[root@bdasfadsfds ~]# java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=2111804480 -XX:MaxHeapSize=32210157568 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

五、小结

垃圾回收器目前分为6种类型, 串行，并行，并发标记，G1。
小数据量和小型应用，使用串行垃圾回收器即可。
对于对响应时间无特殊要求的，可以使用并行垃圾回收器和并发标记垃圾回收器。（中大型应用）
对于heap可以分配很大的中大型应用，使用G1垃圾回收器比较好，进一步优化和减少了GC暂停时间。
没有银弹，针对不同的场景，选用不同的垃圾回收器。

六、流行的组合

Serial
ParNew + CMS
ParallelYoung + ParallelOld
G1GC

七、图像

垃圾回收的4种算法：标记-清除、复制算法、标记-整理算法、分代收集

参考：

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html
http://javapapers.com/java/types-of-java-garbage-collectors/
http://blog.sina.com.cn/s/blog_4080505a0101i6cr.html
http://www.techpaste.com/2012/02/20/default-jvm-settings-gc-jit-java-heap-sizes-xms-xmx-operating-systems/#more-3569
http://docs.oracle.com/javase/1.5.0/docs/guide/vm/server-class.html
https://blog.csdn.net/oopsoom/article/details/40374897
http://www.importnew.com/23752.html
https://javapapers.com/java/types-of-java-garbage-collectors/
https://my.oschina.net/hosee/blog/644618
http://xinklabi.iteye.com/blog/1767666
http://blog.51cto.com/sunbean/768034