解读Java虚拟机垃圾回收器：探究经典算法背后的奥秘

一、GC分类与性能指标

（一）垃圾回收器分类

（二）性能指标

（三）不可能三角

二、不同的垃圾回收器概述

三、Serial回收器：串行回收

四、ParNew回收器：并行回收

五、Parallel回收器：吞吐量优先

六、CMS回收器：低延迟

七、G1回收器：区域化分代式

（一）Region

（二）记忆集

（三）运行过程

八、垃圾回收器总结

九、GC日志分析

一、GC分类与性能指标

（一）垃圾回收器分类

1、按垃圾回收线程数

串行回收指同一个时间段内，只允许一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直到垃圾收集工作结束。在单CPU处理器或者较小应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以串行回收默认被应用在客户端的client模式下的JVM中

并行垃圾回收器，和串行相反，并行收集可以运用在多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了STW机制

2、按照工作模式分

并发式：垃圾回收器与应用程序交替工作，以尽可能减少应用程序的停顿时间

独占式：一旦运行，就停止应用程序中所有的用户线程，直到垃圾回收过程完全结束

3、按照碎片处理方式

压缩式，比如标记整理算法，内存分配可以使用指针碰撞。

非压缩式，比如标记清除算法，会产生垃圾碎片，内存分配使用空闲列表

4、按个工作内存区间分

年轻代

老年代

（二）性能指标

1、吞吐量

运行用户代码的时间占总运行时间的比例

总运行时间：程序的运行时间+内存回收的时间

吞吐量优先，意味着单位时间内，STW的时间最短

2、垃圾收集开销

吞吐量的补数（运行时间=运行用户代码的时间+垃圾回收的时间），垃圾收集所占用的时间与总运行时间的比例

3、暂停时间

执行垃圾收集时，程序的工作线程被暂停的时间

暂停时间优先，意味着单次STW的时间最短，但是频率可能增加

4、收集频率

相对于应用程序的执行，收集操作发生的频率

5、内存占用

Java堆区所占的内存大小

6、快速

一个对象从诞生到被回收经历的时间

（三）不可能三角

简单来说抓住两点，吞吐量和暂停时间

高吞吐量与低暂停时间，是一对互相竞争的。因为如果高吞吐量优先，必然需要降低内存回收的执行频率，导致GC需要更长的暂停时间来执行内存回收。

如果选择低暂停时间（低延迟）优先为原则，也只能频繁的执行内存回收，引起程序吞吐量的下降

现在的标准，在最大吞吐量优先的情况下，降低停顿时间（STW）

二、不同的垃圾回收器概述

7款经典垃圾收集器和垃圾分代之间的关系

垃圾收集器的组合关系

jdk8之前，可以用虚线参考关系
CMS下面的实线，是CMS回收失败的后备方案
JDK8中取消了红线的组合，标记为废弃的。如果要用也可以用。
JDK9中将红线做了remove
jdk14中弃用了绿线组合
jdk14中删除了CMS GC
JDK9默认G1
JDK8默认Parallel Scavenge 和Parallel old Gc
新生代用了Parallel Scavenge 则老年代自动触发用Parallel old
Parallel底层与ParNew底层不同，所以不能和CMS组合

如何查看默认的垃圾收集器？

-XX:+PrintCommandLineFlags
jinfo -flag 相关垃圾回收器参数进程ID

三、Serial回收器：串行回收

Serial收集器采用复制算法，串行回收和STW机制的方式执行内存回收。除了年轻代，还有用于执行老年代的Serial old收集器，同样采取了串行回收，但是用标记压缩算法。

使用一个CPU或者一条收集线程去完成垃圾收集工作，在进行垃圾收集时，必须暂停其他所有工作线程

优势：简单而高效，对于限定单个CPU的环境来说，由于没有线程交互的开销，可以获取最高的单线程收集效率

HotSpot虚拟机中，使用-XX:+UseSerialGC指定年轻代和老年代使用串行收集器

对于交互强的应用而言，并不会采取串行垃圾收集器

四、ParNew回收器：并行回收

除了采用并行回收，其他方面和Serial之间几乎没有任何区别

-XX:UseParNewGC 手动指定ParNew收集器执行内存回收任务，它表示年轻代使用，不影响老年代

-XX:ParallelGCThreads 限制线程数量，默认开启和CPU数据相同的线程数

五、Parallel回收器：吞吐量优先

也采用并行回收，同样是基于标记-复制算法实现的，但和ParNew不同，它的目标是达到一个可控制的吞吐量。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值，

即：

Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间

的 -XX：MaxGCPauseMillis 参数以及直接设置吞吐量大小的 -XX：GCTimeRatio 参数。

接下来介绍参数

-XX:+UseParallelGC
- 手动指定年轻代使用此收集器执行内存回收任务
-XX:+UseParallelOldGC
- 手工指定老年代使用并行回收收集器，分别适用于新生代和老年代，默认jdk8是开启的
- 上面这两个参数相互关联，开启一个，默认开启另一个。
-XX:ParallelGCThreads
- 设置年轻代并行收集器的线程数，一般与CPU数量相同，如果CPU数量大于8个，则值=3+（5*N/8）
-XX:MaxGCPauseMillis
设置收集器最大停顿时间，单位毫秒。允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过用户设定值。
-XX:GCTimeRatio
- 垃圾收集占总时间比，用于衡量吞吐量大小
- 默认99，取值范围0-100，也就是垃圾回收时间不超过1%
- 与上一个参数矛盾，暂停时间越长，Ratio参数就容易超过设定比例
-XX:+UseAdaptiveSizePolicy
- 开启自适应调节策略。这种模式下，年轻代大小，Eden和Survivor的比例，晋升老年底对象年龄参数都会被自动调整
- 为了达到堆大小，吞吐量和停顿时间之间的平衡点
- 在手动调优比较困难的场景下，可以直接用自适应方式，仅指定虚拟机最大堆，目标吞吐量和停顿时间，让虚拟机自己完成调优工作

六、CMS回收器：低延迟

jdk1.5推出 Concurrent Mark Sweep 并发的标记清除，第一次实现了让垃圾收集线程与用户线程同时工作

从名字（包含 “Mark Sweep” ）上就可以看出 CMS 收集器是基于标记 - 清除算法实现的，它的运作

过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤，包括：

初始标记：STW，仅仅只是标记处GC Roots能直接关联的对象，一旦标记完成后就会恢复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里速度非常快
并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但是不需要停顿用户线程。可以与垃圾收集线程一起并发运行
重新标记：为了修正并发标记期间，因用户程序继续运作导致标记产生变动的那一部分对象的标记记录
并发清除：清理删除标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发

初始标记和重新标记阶段仍然需要STW机制

而且由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此CMS收集器不能像其他收集器那样等到老年代几乎填满再进行回收，而是当堆内存使用率达到某一阈值时，便开始进行回收。

要是CMS运行期间预留的内存无法满足程序需要，就会出现一次Concurrent Mode Failure失败，这时虚拟机启用备用方案，临时启用Serial old 收集器来重新进行老年代的垃圾收集，这样停顿时间就长了。

CMS采取标记清除算法，会产生内存碎片，只能够选择空闲列表执行内存分配

为什么不采取标记压缩呢？

因为并发清除时，如果用压缩整理内存，原来的用户线程使用的内存就无法使用了。标记压缩更适合STW场景下使用

优点

并发收集
低延迟

缺点

会产生内存碎片
对CPU资源非常敏感
- 在并发阶段会占用一部分线程导致应用程序变慢
无法处理浮动垃圾
- 并发标记阶段是与工作线程同时运行，如果并发阶段产生垃圾对象，CMS无法进行标记，导致新产生的垃圾对象没有被及时回收，只能在下一次执行GC时释放空间

接下来介绍参数

-XX:+UseConcMarkSweepGC
- 手工指定CMS收集器执行内存回收任务
- 开启后，自动将-XX:UseParNewGC打开，即ParNew（Young区）+CMS（old区）+Serial GC组合
-XX:CMSlnitiatingOccupanyFraction
- 设置堆内存使用率的阈值
- 一旦达到该阈值，则开始进行回收
- jdk5及之前默认68，即老年代的空间使用率达到68%时会执行一次CMS回收
- JDK6及以上默认值为92%
- 如果内存增长缓慢，可以设置一个稍大的值，有效降低CMS的触发频率，减少老年代回收的次数
- 如果应用程序内存使用率增加很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。
-XX:+UseCMSCompactAtFullCollection
- 用于执行完Full GC后对内存空间进行压缩整理
- 不过内存压缩无法并发执行，会带来停顿时间更长的问题
-XX:CMSFullGCsBeforeCompaction
- 设置执行多少次FullGC后对内存空间进行压缩整理
-XX:ParallelCMSThreads
- 设置CMS的线程数量
- 默认启动的线程数是(ParallelGCThreads+3)/4
- ParallelGCThreads是年轻代并行收集器的线程数

如果想要最小化使用内存和并行开销，选择Serial GC

如果最大化应用程序的吞吐量，选择ParallelGC

如果想要最小化的GC的中断或停顿时间，选择CMS GC

七、G1回收器：区域化分代式

官方给G1设定的目标就是在延迟可控的情况下，获得尽可能高的吞吐量，所以才担当起全功能收集器的重任和期望

在JDK1.7版本正式启用，jdk9以后默认垃圾回收器。JDK8还不是默认的，需要用-XX:+UseG1GC来启用

（一）Region

Garbage First是一个并行回收器，他把堆内存分割为很多不相关的区域（Region）（物理上不连续），使用不同的region表示Eden，s0，s1，老年代等。G1会跟踪各个region里面垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region

收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

Region 中还有一类特殊的 Humongous 区域，专门用来存储大对象。 G1 认为只要大小超过了一个

Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数 -XX： G1HeapRegionSize 设定，取值范围为1MB ～ 32MB ，且应为 2 的 N 次幂。而对于那些超过了整个 Region 容量的超级大对象，将会被存放在N 个连续的 Humongous Region 之中， G1 的大多数行为都把 Humongous Region 作为老年代的一部分来进行看待。

将Java堆分成多个独立Region后，Region里面存在的跨Region引用对象如何解决？

比如进行新生代垃圾回收时，很有可能有老年代的对象指向新生代中的对象，如果此时还需对老年代的对象进行一次扫描，代价太高昂了。G1收集器使用记忆集来解决这个问题

（二）记忆集

每个region对应一个记忆集，通过记忆集避免全局扫描。这些记忆集会记录下别的Region 指向自己的指针，并标记这些指针分别在哪些卡页的范围之内。

每次引用类型数据写操作时，会产生一个写屏障暂时中断操作。然后检查将要赋值的引用指向的对象是否和该引用对象类型数据在不同的region，如果不同就通过CardTable把相关的引用信息记录到引用指向对象所在的Region对应的记忆集中

当进行垃圾收集时，在GC根节点枚举范围加入记忆集，就可以保证不进行全局扫描，也不会有遗漏

（三）运行过程

如果我们不去计算用户线程运行过程中的动作（如使用写屏障维护记忆集的操作）， G1 收集器的

运作过程大致可划分为以下四个步骤：

初始标记 （ Initial Marking ）：仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region 中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC 的时候同步完成的，所以 G1 收集器在这个阶段实际并没有额外的停顿。

并发标记 （ Concurrent Marking ）：从 GC Root 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。

最终标记 （ Final Marking ）：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留

下来的最后那少量的 SATB 记录。

筛选回收 （ Live Data Counting and Evacuation ）：负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region 构成回收集，然后把决定回收的那一部分Region 的存活对象复制到空的 Region 中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的

优势

并行与并发
分代收集：同时兼顾年轻代与老年代
空间整合
- region之间用复制算法，整体可以看做是标记压缩算法。
- 两种算法都避免内存碎片，有利于程序长时间运行，分配大对象不会因为无法找到连续空间提前触发下一次GC，尤其当Java堆非常大的时候，G1优势更加明显
可预测的停顿时间模型
- 能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不能超过N毫秒

缺点

相较于CMS，G1不具备全方位，压倒性优势。比如用户程序运行中，G1无论是为了垃圾收集产生的内存占用，还是程序运行时的额外执行负载都要比CMS要高
经验上来说，小内存应用CMS表现大概率优于G1，在大内存上G1优势发挥更多，平衡点再6-8GB

参数设置

-XX:+UseG1GC
-XX:G1HeapRegionSize
- 设置每个Region大小，值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆划分出约2048个区域，默认是堆内存的1/2000
-XX:MaxGCPauseMillis
- 设置期望达到的最大GC停顿时间指标，JVM尽力但不保证，默认200ms
-XX:ParallelGCThread
- 设置STW工作线程数的值，最多设置8
-XX:ConcGCThreads
- 设置并发标记的线程数，将N设置为并行垃圾回收线程数（parallelGCThreads）的1/4左右
-XX:InitiatingHeapOccupancyPercent
- 设置触发并发GC周期的Java堆占用率阈值，超过此值就触发GC，默认是45

G1提供了三种垃圾回收模式在不同的条件下触发