编程语言
首页 > 编程语言> > 垃圾收集器及垃圾回收算法

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

作者:互联网

1 什么样的对象需要回收?

自动化的管理内存资源,垃圾回收机制必须要有一套算法来进行计算,哪些是有效的对象,哪些是无效的对象,对于无效的对象就要进行回收处理。常见计算无效对象的方法有两种,分别是:引用计数算法、可达性分析算法。

1.1 引用计数法

在对象中添加一个引用计数器,每当有一个地方引用它,计数器值就加一;当引用失效时,计数器就减一;任何时刻计数器为零的对象就是不可能再被使用。
但是,在Java领域,至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存,主要原因是引用计数发有很多例外的情况,比如对象之间相互引用的问题。

1.2 可达性分析算法

通过一系列称为“GC Roots”的根对象作为起始节点集,从这些节点开始,根据引用关系向下搜索,搜索过程所走过的路径称为“引用链”(Reference Chain),如果某个对象到GC Roots间没有任何引用链相连,就说明从GC Roots 到这个对象不可达时,则证明此对象是不可能再被使用的,就是可以回收的对象。

在JVM虚拟机中,可作为GC Roots的对象包括以下几种:

1.3 对象的引用

在java中,对象的引用分为:强引用(Strongly Re-ference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)4种。
强引用

2 垃圾收集算法

2.1 标记清除法

标记清除算法,是将垃圾回收分为2个阶段,分别是标记和清除。
标记:从根节点开始标记引用的对象。
清除:未被标记引用的对象就是垃圾对象,可以被清理。
标记清除法可以说是最基础的收集算法,因为后续的收集算法大多都是以标记-清除算法为基础,对其缺点进行改进而得到的。
执行过程:

缺点:

2.2 标记压缩

标记压缩算法是在标记清除算法的基础之上,做了优化改进的算法。和标记清除算法一样,也是从根节点开始,对对象的引用进行标记,在清理阶段,并不是简单的清理未标记的对象,而是将存活的对象压缩到内存的一端,然后清理边界以外的垃圾,从而解决了碎片化的问题

该算法解决了标记清除算法的碎片化的问题,同时,标记压缩算法多了一步,对象移动内存位置的步骤,其效率也有一定的影响。

2.3 标记复制算法

复制算法的核心就是,将原有的内存空间一分为二,每次只用其中的一块,在垃圾回收时,将正在使用的对象复制到另一个内存空间中,然后将该内存空间清空,交换两个内存的角色,完成垃圾的回收。
如果内存中的垃圾对象较多,需要复制的对象就较少,这种情况下适合使用该方式并且效率比较高,反之,则不适合。

优点:
在垃圾对象多的情况下,效率较高
清理后,内存无碎片

缺点:
在垃圾对象少的情况下,不适用,如:老年代内存
分配的2块内存空间,在同一个时刻,只能使用一半,内存使用率较低

JVM中年轻代内存空间
JVM年轻代使用的标记复制算法。

2.4 分代算法

在堆内存中,有些对象短暂存活有些则是长久存活,所以需要将堆内存进行分代,将短暂存活的对象放到一起,进行高频率的回收,长久存活的对象集中放到一起,进行低频率的回收,这样才能够更加合理的利系统资源。
分代算法其实就是这样的,根据回收对象的特点进行选择,在jvm中,年轻代适合使用复制算法,老年代适合使用 标记清除或标记压缩算法。
垃圾回收的相关概念:

3 垃圾收集器

垃圾收集器是针对垃圾算法的实现。JDK诞生Serial追随,提高效率诞生了PS ,为了配合CMS,诞生了PN,CMS是1.4版本后期引入,CMS是里程碑式的GC,它开启了并发回收的过程(避免STW:Stop-The-World),但是CMS毛病比较多,因此目前任何一个JDK版本默认的都不是CMS。

在HotSpot虚拟机中,常见的集中垃圾收集器组合方式,如下图连线即可以组合,常见的组合Serial-Serial Old、Parallel Scavenge-Parallel Old、ParNew-CMS、G1、ZGC。

3.1 串行垃圾收集器

串行垃圾收集器,是指使用单线程进行垃圾回收,垃圾回收时,只有一个线程在工作,并且java应用中的所有线程 都要暂停,等待垃圾回收的完成。这种现象称之为STW(Stop-The-World)。对于交互性较强的应用而言,这种垃圾收集器是不能够接受的。
一般在Javaweb应用中是不会采用该收集器的。

3.2 并行垃圾收集器

并行垃圾收集器在串行垃圾收集器的基础之上做了改进,将单线程改为了多线程进行垃圾回收,这样可以缩短垃圾回收的时间。(这里是指,并行能力较强的机器)。
当然了,并行垃圾收集器在收集的过程中也会暂停应用程序,这个和串行垃圾回收器是一样的,只是并行执行,速度更快些,暂停的时间更短一些。

3.2.1 ParNew垃圾收集器

ParNew垃圾收集器是工作在年轻代上的,只是将串行的垃圾收集器改为了并行。 通过-XX:+UseParNewGC参数设置年轻代使用ParNew回收器,老年代使用的依然是串行收集器。

3.2.2 ParallelGC垃圾收集器

ParallelGC收集器工作机制和ParNewGC收集器一样,只是在此基础之上,新增了两个和系统吞吐量相关的参数,使得其使用起来更加的灵活和高效。
相关参数如下:
-XX:+UseParallelGC
年轻代使用ParallelGC垃圾回收器,老年代使用串行回收器。
-XX:+UseParallelOldGC
年轻代使用ParallelGC垃圾回收器,老年代使用ParallelOldGC垃圾回收器。
-XX:MaxGCPauseMillis
设置最大的垃圾收集时的停顿时间,单位为毫秒。需要注意的时,ParallelGC为了达到设置的停顿时间,可能会调整堆大小或其他的参数,如果堆的大小 设置的较小,就会导致GC工作变得很频繁,反而可能会影响到性能。该参数使用需谨慎。
-XX:GCTimeRatio
设置垃圾回收时间占程序运行时间的百分比,公式为1/(1+n)。它的值为0~100之间的数字,默认值为99,也就是垃圾回收时间不能超过1%
-XX:UseAdaptiveSizePolicy
自适应GC模式,垃圾回收器将自动调整年轻代、老年代等参数,达到吞吐量、堆大小、停顿时间之间的平衡。一般用于,手动调整参数比较困难的场景,让收集器自动进行调整。

3.3 CMS垃圾收集器

CMS全称 Concurrent Mark Sweep,是一款并发的、使用标记-清除算法的垃圾回收器,该回收器是针对老年代垃 圾回收的,通过参数-XX:+UseConcMarkSweepGC进行设置。

3.4 G1垃圾收集器

G1垃圾收集器是在jdk7中正式使用的全新的垃圾收集器,oracle官方计划在jdk9中将G1变成默认的垃圾收集器,以替代CMS。
JDK9默认G1为垃圾收集器的提案:https://openjdk.java.net/jeps/248
将CMS标记为丢弃的提案:https://openjdk.java.net/jeps/291

G1的设计原则就是简化JVM性能调优,开发人员只需要简单的三步即可完成调优:
第一步,开启G1垃圾收集器;
第二步,设置堆的最大内存;
第三步,设置最大的停顿时间(使用参数 -XX:MaxGCPauseMillis指定,默认200毫秒)。
G1中提供了三种模式垃圾回收模式,Young GC、Mixed GC 和 Full GC,在不同的条件下被触发。

3.4.1 原理

G1垃圾收集器相对比其他收集器而言,最大的区别在于它取消了年轻代、老年代的物理划分,取而代之的是将堆划分为若干个大小相等的独立区域(Region),每个Region区域都可以根据需要,扮演新生代的Eden空间、Survivor空间或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理。
这样做的好处就是,我们再也不用单独的空间对每个代进行设置了,不用担心每个代内存是否足够。

在G1划分的区域中,年轻代的垃圾收集依然采用暂停所有应用线程的方式,将存活对象拷贝到老年代或者Survivor 空间,G1收集器通过将对象从一个区域复制到另外一个区域,完成了清理工作。
这就意味着,在正常的处理过程中,G1完成了堆的压缩(至少是部分堆的压缩),这样也就不会有cms内存碎片问题的存在了。
在G1中,有一种特殊的区域,叫Humongous区域。

3.4.2 Young GC

Young GC主要是对Eden区进行GC,它在Eden空间耗尽时会被触发。

每个Region初始化时,会初始化一个RSet,该集合用来记录并跟踪其它Region指向该Region中对象的引用,每个 Region默认按照512Kb划分成多个Card,所以RSet需要记录的东西应该是 xx Region的 xx Card。

3.4.3 Mixed GC

在G1收集器之前所有其他收集器,包括CMS在内,垃圾收集的目标范围要么是整个新生代,要么是整个老年代,或者是整个Java 堆。而G1跳出了这个樊笼,它可以面向堆内存任何部分来组成回收器进行回收。衡量标准不再是它属于哪个分代,而是哪块内存中存放的垃圾数量最多,回收收益最大,这就是G1的Mixed GC模式。

当越来越多的对象晋升到老年代old region时,为了避免堆内存被耗尽,虚拟机会触发一个混合的垃圾收集器,即 Mixed GC,该算法并不是一个Old GC,除了回收整个Young Region,还会回收一部分的Old Region,这里需要注 意:是一部分老年代,而不是全部老年代,可以选择哪些old region进行收集,从而可以对垃圾回收的耗时时间进 行控制。也要注意的是Mixed GC 并不是 Full GC。
MixedGC什么时候触发? 由参数 -XX:InitiatingHeapOccupancyPercent=n 决定。默认:45%,该参数的意思是: 当老年代大小占整个堆大小百分比达到该阀值时触发。
它的GC步骤分2步:
1)全局并发标记(global concurrent marking)
2)拷贝存活对象(evacuation)
全局并发标记

全局并发标记,执行过程分为五个步骤:

3.4.4 G1收集器相关参数

3.4.5 G1垃圾收集器优化建议

年轻代大小

3.5 ZGC

ZGC收集器是一款基于Region内存布局的,不设分代的,使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的,以低延迟为首要目标的一款垃圾回收器。(选自《深入理解Java虚拟机》第3版 P112页)

3.5.1 内存布局

ZGC的内存布局与G1一样,也采用基于Region的堆内存布局,但不同的是,ZGC的Page(ZGC中称之为页面,道理和Region一样)具有动态性——动态创建和销毁,以及动态的区域容量大小。在x64硬件平台下,ZGC的Page可以具有大、中、小三类容量:

3.5.2 性能表现

在性能方面,尽管目前还处于实验状态,还没有完成所有特性,稳定性打磨和性能调优也仍在进行,但即使是这种 状态下的ZGC,其性能表现已经相当亮眼,从官方给出的测试结果来看,用“令人震惊的、革命性的ZGC”来形容都 不为过。
A3EA03D6-EE10-4747-B596-52C94E166F22

ZGC与Parallel Scavenge、G1三款收集器通过SPECjbb 2015(java服务器业务测试工具)的测试结果。在ZGC 的“弱项”吞吐量方面,以低延迟为首要目标的ZGC已经达到了以高吞吐量为目标Parallel Scavenge的99%,直接超 越了G1。如果将吞吐量测试设定为面向SLA(Service Level Agreements)应用的 “Critical Throughput” (要求最大延迟不超过某个设置值(10毫秒到100毫秒)下测得的吞吐量)的话,ZGC的表现甚至还反超了Parallel Scavenge收集器。


ZGC的强项停顿时间测试上,它就毫不留情地与Parallel Scavenge、G1拉开了两个数量级的差距。不论是平均停 顿,还是95%停顿、99%停顿、99.9%停顿,抑或是最大停顿时间,ZGC均能毫不费劲地控制在十毫秒之内,以至于把它和另外两款停顿数百近千毫秒的收集器放到一起对比,就几乎显示不了ZGC的柱状条(图a),必须把结果的纵坐标从线性尺度调整成对数尺度(图b,纵坐标轴的尺度是对数增长的)才能观察到ZGC的测试结果。

3.5.3 染色指针技术

ZGC为了实现目标,新增了染色指针技术。

染色指针是一种直接将少量额外的信息存储在指针上的技术,在64位系统中,理论可以访问的内存高达16EB(2的 64次幂)字节。实际上,64位的Linux则分别支持47位(128TB)的进程虚拟地址空间和46位(64TB)的物理地 址空间,64位的Windows系统甚至只支持44位(16TB)的物理地址空间。
Linux下64位指针的高18位不能用来寻址,但剩余的46位指针所能支持的64TB内存在今天仍然能够充分满足大型服务器的需要。
ZGC的染色指针技术使用上了这剩下的46位指针宽度,将其高4位提取出来存储四个标志信息。 通过这些标志位,虚拟机可以直接从指针中看到其引用对象的三色标记状态、是否进入了重分配集(即被移动过)、是否只能通过finalize()方法才能被访问到。 由于这些标志位进一步压缩了原本就只有46位的地址空间,也直接导致ZGC能够管理的内存不可以超过4TB(2的42次幂)。
染色指针的好处:

3.5.4 ZGC工作过程

ZGC的运作过程大致可划分为四个大的阶段,这四个阶段都是可以并发执行的。仅在Mark Start、Initial Mark 阶段中会存在短暂的STW。

标签:G1,收集器,对象,回收,算法,GC,垃圾
来源: https://www.cnblogs.com/dooor/p/jvmlj.html