JVM学习笔记03-垃圾收集器及GC参数

前言

有哪些垃圾收集器?
GC参数有哪些？
JVM默认使用哪些垃圾收集器?
请带着以上疑问耐心阅读全文。

垃圾收集器概述

一、垃圾收集器分类:

Java 堆内存被划分为新生代和年老代两部分，新生代主要使用复制和标记-清除垃圾回收 算法 ；年老代主要使用标记-整理垃圾回收算法，因此 java 虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器:

串行收集器：Serial收集器(单线程、 复制算法)

Serial（英文连续）是最基本垃圾收集器，使用复制算法，曾经是JDK1.3.1之前新生代唯一的垃圾收集器。Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。
Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个 CPU 环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此 Serial垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器。
总结:
最古老，最稳定
简单而高效
可能会产生较长的停顿
参数:-XX:+UseSerialGC
新生代、老年代都会使用串行回收
新生代使用复制算法
老年代使用标记-整理
收集器的运行过程如下图所示：

并行收集器：ParNew 垃圾收集器（ （Serial+多线程）

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。
ParNew 收集器默认开启和 CPU 数目相同的线程数，可以通过-XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】ParNew虽然是除了多线程外和Serial收集器几乎完全一样，但是ParNew垃圾收集器是很多java虚拟机运行在 Server 模式下新生代的默认垃圾收集器。
总结:
ParNew收集器其实就是Serial收集器新生代的并行版本。
多线程，需要多核支持。
-XX:+UseParNewGC
　　　　新生代并行
　　　　老年代串行
-XX:ParallelGCThreads 限制线程数量

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证能超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄就4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

Parallel Scavenge 收集器 收集器（多线程复制算法、高效）

类似ParNew，但更加关注吞吐量
-XX:+UseParallelGC 使用Parallel Scanvenge收集器：新生代并行，老年代串行

Parallel Old收集器：
Parallel Old收集器是Parallel Scanvenge收集器的老年代版本
-XX:+UseParallelGC 使用Parallel Old收集器：新生代并行，老年代并行

各种参数设置：

-XX:MaxGCPauseMills
　　　　最大停顿时间，单位毫秒

GC尽力保证回收时间不超过设定值

-XX:GCTimeRatio
　　　　0-100的取值范围

垃圾收集时间占总时间的比

默认99，即最大允许1%时间做GC

注：这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。我们一方买希望停顿时间少，另外一方面希望吞吐量高，其实这是矛盾的。因为：在GC的时候，垃圾回收的工作总量是不变的，如果将停顿时间减少，那频率就会提高；既然频率提高了，说明就会频繁的进行GC，那吞吐量就会减少，性能就会降低。

吞吐量：CPU用于用户代码的时间/CPU总消耗时间的比值，即=运行用户代码的时间/(运行用户代码时间+垃圾收集时间)。比如，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

注2：以上所有的收集器当中，当执行GC时，都会stop the world，但是下面的CMS收集器却不会这样。

CMS收集器

CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。

Concurrent Mark Sweep 并发标记清除，并发低停顿
标记-清除算法
并发阶段会降低吞吐量（因为停顿时间减少了，于是GC的频率会变高）
老年代收集器（新生代使用ParNew）
-XX:+UseConcMarkSweepGC 打开这收集器
注：这里的并发指的是与用户线程一起执行。

2、CMS收集器运行过程：（着重实现了标记的过程）

（1）初始标记

根可以直接关联到的对象

速度快

（2）并发标记（和用户线程一起）

主要标记过程，标记全部对象

（3）重新标记

由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正

（4）并发清除（和用户线程一起）

基于标记结果，直接清理对象

整个过程如下图所示：

其中，初始标记和重新标记时，需要stop the world。

整个过程中耗时最长的是并发标记和并发清除，这两个过程都可以和用户线程一起工作。

打印GC日志举例如下：

3、CMS收集器特点：

（1）尽可能降低停顿

（2）会影响系统整体吞吐量和性能

比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半

（3）清理不彻底

因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理

（4）因为和用户线程一起运行，不能在空间快满时再清理

-XX:CMSInitiatingOccupancyFraction设置触发GC的阈值

如果不幸内存预留空间不够，就会引起concurrent mode failure

我们来看一下concurrent mode failure的日志：

碰到上图中的情况，我们需要使用串行收集器作为后备。

4、既然标记清除算法会造成内存空间的碎片化，CMS收集器为什么使用标记清除算法而不是使用标记整理算法：

答案：

CMS收集器更加关注停顿，它在做GC的时候是和用户线程一起工作的（并发执行），如果使用标记整理算法的话，那么在清理的时候就会去移动可用对象的内存空间，那么应用程序的线程就很有可能找不到应用对象在哪里。

为了解决碎片的问题，CMS收集器会有一些整理上的参数，接下来就来讲这个。

5、整理时的各种参数：
-XX:+ UseCMSCompactAtFullCollection
Full GC后，进行一次整理。整理过程是独占的，会引起停顿时间变长

-XX:+CMSFullGCsBeforeCompaction
设置进行几次Full GC后，进行一次碎片整理

-XX:ParallelCMSThreads
设定CMS的线程数量

G1收集器

Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器，G1 收
集器两个最突出的改进是：

1. 基于标记-整理算法，不产生内存碎片。
2. 可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。
   G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域
   的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾
   最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收
   集效率。

GC参数的整理

-XX:+UseSerialGC：在新生代和老年代使用串行收集器

-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例

-XX:NewRatio:新生代和老年代的比

-XX:+UseParNewGC：在新生代使用并行收集器

-XX:+UseParallelGC ：新生代使用并行回收收集器

-XX:+UseParallelOldGC：老年代使用并行回收收集器

-XX:ParallelGCThreads：设置用于垃圾回收的线程数

-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器

-XX:ParallelCMSThreads：设定CMS的线程数量

-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发

-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理

-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩

-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收

-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收

-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收

最后的总结：

为了减轻GC压力，我们需要注意些什么？

1.软件如何设计架构（性能的根本在应用）
2.GC参数属于微调（设置不合理会影响性能，产生大的延时）
3.堆空间如何管理和分配
4.代码如何写

查看JVM使用的垃圾收集器

执行命令：
java -XX:+PrintCommandLineFlags -version
输出如下（举例）：

针对上述的-XX：UseParallelGC，这边我们引用《深入理解Java虚拟机：JVM高级特性与最佳实践》的介绍：

如图所示:使用的垃圾收集器是：新生代（Parallel Scavenge），老年代（Ps MarkSweep）组合。