JVM垃圾收集算法及垃圾收集器

最新推荐文章于 2023-02-06 11:58:39 发布

迷路的小羊

最新推荐文章于 2023-02-06 11:58:39 发布

阅读量185

点赞数

文章标签： jvm java 垃圾回收算法

本文链接：https://blog.csdn.net/weixin_40114067/article/details/115256078

版权

JVM的分代收集理论

分代收集思想就是根据划分的不同内存区域采取不同的收集算法，基本的收集算法有三种： 复制算法，标记-清除，标记-整理。

标记-复制算法

复制算法将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
原理图如下
在这里插入图片描述

标记-清除

算法分为“标记”和“清除”阶段:标记存活的对象，统一回收所有未被标记的对象(一般选择这种);也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，比较简单，但是会带来两个明显的问题：

效率问题 (如果需要标记的对象太多，效率不高)
空间问题(标记清除后会产生大量不连续的碎片)
原理图如下

标记-整理

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
原理图如下
在这里插入图片描述

在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

垃圾收集器

现在目前存在以下十种垃圾收集器
在这里插入图片描述
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
没有最好的垃圾收集器，只有更加完善适合的收集器。

1.Serial收集器（-XX:+UseSerialGC -XX:+UseSerialOldGC）

Serial(串行)收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程( “Stop The World” )，直到它收集结束。 新生代采用复制算法，老年代采用标记-整理算法。
方式如下
在这里插入图片描述
单线程带来的缺点就是严重降低用户体验，优点就是简单而高效。
Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途:一种用途是在JDK1.5 以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

2.Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为(控制参数、收集算法、回收策略等等)和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(- XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量(高效率的利用CPU)。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间(提高用户体验)。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。
新生代采用复制算法，老年代采用标记-整理算法。
方式如下
在这里插入图片描述
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。

3.ParNew收集器(-XX:+UseParNewGC)

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。
新生代采用复制算法，老年代采用标记-整理算法。
方式如下：
在这里插入图片描述
它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器(真正意义上的并发收集器，后面会介绍到)配合工作。

4.CMS收集器(-XX:+UseConcMarkSweepGC(old)) （重点掌握）

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程 (基本上)同时工作。
整个过程分为五个步骤:

初始标记: 暂停所有的其他线程(STW)，并记录下gc roots（线程栈的本地变量、静态变量、本地方法栈的变量等等）直接能引用的对象，速度很快。
并发标记: 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。（产生浮动垃圾）
重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。（也会STW，产生浮动垃圾）
并发清理: 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。
并发重置:重置本次GC过程中的标记数据。
方式图如下

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点:并发收集、低停顿。但是它有下面几个明显的缺点:
跟CPU抢资源（在并发阶段）
无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了);
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数- XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收
CMS的相关核心参数
-XX:+UseConcMarkSweepGC:启用cms
-XX:ConcGCThreads:并发的GC线程数
-XX:+UseCMSCompactAtFullCollection:FullGC之后做压缩整理(减少碎片)
-XX:CMSFullGCsBeforeCompaction:多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC(默认是92，这是百分比) 6. -XX:+UseCMSInitiatingOccupancyOnly:只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
-XX:+CMSScavengeBeforeRemark:在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
-XX:+CMSParallellnitialMarkEnabled:表示在初始标记的时候多线程执行，缩短STW
-XX:+CMSParallelRemarkEnabled:在重新标记的时候多线程执行，缩短STW;

5.G1收集器(-XX:+UseG1GC)

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC 停顿时间要求的同时,还具备高吞吐量性能特征.
G1的内存模型如下：
在这里插入图片描述
G1将Java堆划分为多个大小相等的独立区域(Region)，JVM最多可以有2048个Region。
G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是(可以不连续)Region的集合。
一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。
G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%。而且一个大对象如果太大，可能会横跨多个Region来存放。
G1收集器一次GC的运作过程大致分为以下几个步骤:

初始标记（STW）:暂停所有线层，只标记gc roots直接引用的对象，速度很快。
并发标记：同CMS的并发标记。
最终标记（STW）:同CMS的重新标记。
筛选回收（STW）:筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定,默认200ms)来制定回收计划，也就是说，为了满足STW总时间能满足，可能最终只会回收一部分region，剩下的region得等到下一次回收。回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意:CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)。
图例：

G1垃圾收集分类

YoungGC YoungGC
并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC
MixedGC
不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的 Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做 MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC
Full GC
停止系统程序，然后采用单线程(serial Old)进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这
个过程是非常耗时的。(Shenandoah优化成多线程收集了)

G1收集器参数设置

-XX:+UseG1GC:使用G1收集器
-XX:ParallelGCThreads:指定GC工作的线程数量 -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区 -XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)
-XX:G1MaxNewSizePercent:新生代内存最大空间 -XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
-XX:MaxTenuringThreshold:最大年龄阈值(默认15)
-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了
-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。
-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

什么场景适合使用G1

50%以上的堆被存活对象占用
对象分配和晋升的速度变化非常大
垃圾回收时间特别长，超过1秒
8GB以上的堆内存(建议值)
停顿时间是500ms以内

垃圾收集算法底层标记原理

三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。这里我们引入“三色标记”来给大家解释下，把Gcroots可达性分析遍历对象过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色。

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的。
灰色：表示对象被收集器访问过，但是没有完全访问完，还有未访问的子对象。
白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。
访问过程中某一刻的对象颜色可能如下：

多标-浮动垃圾

在并发标记过程中，有些对象被标为非垃圾对象，但在结束后就变为垃圾对象了，此时因为被标为黑色，所以不会被此次垃圾收集器清理，只能等下次收集，这样的对象成为浮动垃圾。

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，漏标出现的情况只有同时满足以下两个条件才行：

在并发标记过程中，灰色对象与一个未被扫描的白色对象的引用被删除
在并发标记过程中，已被扫描过的黑色对象新增了一个白色对象的引用

为什么要同时满足呢，因为如果并发标记完后还是白色对象都会被当做垃圾处理，只有是从灰色对象上掉落下来的白色对象又新增到黑色对象上，这个白色对象才会最终被收集器漏扫描而变成垃圾被回收，这就会出现问题了，而针对以上两个条件，就会相应的出现两种解决方案: 增量更新(Incremental Update) 和原始快照(Snapshot At The Beginning，SATB)
增量更新：在并发标记过程中，如果黑色对象又新增加了一个白色对象引用，此时会把这个新加的引用添加到一个数组中，在重新标记阶段会重新扫描这个数组，并把相应的黑色对象置为灰色，也就是说新增引用会让黑色变为灰色。
原始快照：跟增量更新相反，在标记过程中，如果灰色对象有引用被断掉，则会记录被引用对象到数组中，并在重新标记阶段将这些对象全部置为黑色。（目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾）。
所谓的写屏障，其实就是指在赋值操作前后，加入一些处理(可以参考AOP的概念)。写屏障可以实现增量更新（赋值后操作）和原始快照（赋值前操作）。
对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下:

CMS:写屏障 + 增量更新
G1，Shenandoah:写屏障 + SATB
ZGC:读屏障

为什么CMS使用增量更新而G1使用原始快照（SATB）

上面介绍的我们知道G1的内存模型是一个个region，而如果使用增量更新的话，则需要在筛选标记阶段对每个灰色对象再做一次深度扫描，而这都可能频繁的跨代（region）扫描，这就很影响效率，所以使用SATB,只需要标记就行。虽然会产生浮动垃圾。而SMS就只分年轻代和老年代，跨代扫描的情况比较少，所以选择增量更新，这样就不会产生浮动垃圾。

如何选择垃圾收集器

优先调整堆的大小让服务器自己来选择
如果内存小于100M，使用串行收集器
如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
如果允许停顿时间超过1秒，选择并行或者JVM自己选
如果响应时间最重要，并且不能超过1秒，使用并发收集器
4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC
JDK 1.8默认使用 Parallel(年轻代和老年代都是)
JDK 1.9默认使用 G1