JVM——垃圾收集器(五)

本文介绍了JVM常见的垃圾收集器,包括Serial、ParNew、Parallel Scavenge等。阐述了各收集器的特点、适用场景、工作模式及相关参数。如Serial是单线程,ParNew是其多线程版,Parallel Scavenge目标是可控吞吐量,还分析了CMS和G1的优缺点及工作步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、垃圾收集器

收集算法是内存回收的方法论,垃圾收集器是内存回收的具体实现。常见的垃圾收集器及其之间的协作关系如下:
在这里插入图片描述
上面的图中,如果两个收集器之间存在连线,就说明它们可以搭配使用。虚拟机所处的区域,则代表它是属于新生代收集器还是老年代收集器。

1.1、Serial收集器

单线程收集器,它的意思是它只会使用一个CPU或一条收集线程去完成垃圾收集工作,并且在它工作时,必须暂停所有的线程,直到它收集结束(“Stop The World”)。用于Client模式下的新生代收集器,特点是:简单而高效。
Serial/Serial Old收集器的运行过程。
在这里插入图片描述

1.2、ParNew

它其实就是Serial收集器的多线程版本,除了使用多线程进行垃圾收集外,其余行为包括Serial收集器可用的所有参数(例如:+XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法
Stop The World、对象分配规整、回收策略等都与Serial收集器完全一样。
ParNew/Serial Old收集器运行示意图。
在这里插入图片描述
它与Serial收集器相比,除了多线程收集外并没有太多创新。但它是能与CMS收集器配合工作的新生代收集器,所以它是Server模式下首选的新生代收集器。ParNew收集器也是使用:-XX:+UseConcMarkSweepGC选项后的默认新生代收集器,也可以使用-XX:+UseParNewGC选项来强制指定。它默认是启动收集线程数是与CPU的数量是相同的。可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

1.3、Parallel Scavenge收集器

它是一个新生代收集器,也是使用复制算法的并行的多线程收集器。它的目标是达到一个可控的吞吐量,所谓的吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。它提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMIllis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
MaxGCPauseMIllis参数允许的值是一个大于0的毫秒数,收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使系统的垃圾收集速度变快,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。系统把新生代调小一些,会使停顿时间下降,但是会增加垃圾收集的频率,降低吞吐量。
XX:GCTimeRatio参数的值是一个大于0小于100的整数,也就是垃圾收集时间占总时间的比率,相当于吞吐量的倒数。
除了上述参数外,Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy。当这个参数打开之后,就不需要手工设置新生代的大小(-Xmn)、Eden和Survivor区的比例(-XX:SurvivorRatio)、对象直接分配在老年代(-XX:PretenureSizeThreshold)阈值等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或最大吞吐量,这种方式称为GC自适应的调节策略。自适应调节策略也是Parallel Scavenge收集器和ParNew收集器的一个重要区别。

1.4、Serial Old收集器

它是Serial收集器的老年代版本,也是单线程。使用“标记-整理”算法。现在主要用来作为CMS收集器的后备方案,在并发收集发生Concurrent Mode Failure时使用。

1.5、Parallel Old收集器

它是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑Parallel Scavenge和Parallel Old的组合。Parallel Scavenge/Parallel Old收集器工作过程如下:
在这里插入图片描述

1.6、CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前应用与大部分B/S系统的服务器上。它是基于“标记-清除”算法实现,运作过程主要分为4个步骤:
1.初始标记(CMS initial mark)
2.并发标记(CMS concurrent mark)
3.重新标记(CMS remark)
4.初始标记(CMS concurrent sweep)
其中,初始标记时、重新标记两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象,速度很快,并发标记就是进行GC Roots Tracing的过程,而重新标记阶段则是为了修正并发标记阶段因用户程序运行而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般比初始标记稍长一点,但是远比并发标记时间短。
由于整个过程中耗时最长的并发标记和并发清除过程收集器都可以与用户线程一起工作,整体上看CMS的内存回收过程是与用户线程一起并发执行的。
在这里插入图片描述
它的主要优点是:并发收集、低停顿。但是也有3个明显的缺点:
1.CMS收集器对CPU资源非常敏感。它会占用一部分线程而导致程序变慢,总吞吐量降低。CMS默认启动的回收线程数是(CPU数量 + 3)/ 4。
2.CMS无法处理浮动垃圾,可能导致出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。在CMS并发清理阶段用户线程还在运行,这时候就会产生新的垃圾,但是CMS无法在当次处理它们,只好等待下一次GC时,这一部分垃圾就被称为浮动垃圾。也是由于在垃圾收集阶段用户线程还需要运行,那也就需要预留足够的内存空间给用户线程使用,因此CMS收集不能像其他收集器那样等待老年代几乎全被填满再进行收集,需要预留一部分空间供并发收集器用户线程使用。
目前CMS收集器的启动阈值为老年代空间被使用92%时触发收集,要是CMS运行期间预留的内存无法满足程序需要,就会出现一次“Concurrent Mode Failure”失败,这是将启动后备预案,临时启用Serial OLd收集器来收集老年代的垃圾,这样导致停顿时间就很长了。所以-XX:CMSInitiatingOccupancyFraction参数不要设置得太高。
3.由于CMS是基于“标记-清除”算法实现的,就会导致收集结束时会产生大量的空间碎片,但需要给大对象分配空间时,往往会出现老年代还有很大空余空间,但是无法找到足够大的连续空间来分配给当前对象,不得不提前触发一次Full GC。参数-XX:CMSFullGCBeforeCompaction表示执行多少次不压缩内存的Full GC后,执行一次压缩。

1.7、G1收集器

G1是一款面向服务端的垃圾收集器,与CMS收集器相比,G1有如下特点:
1.并发与并行:G1能充分利用多CPU、多核环境下的硬性优势,使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World停顿的时间,部分其他收集器原本需要停顿java线程执行的GC动作,G1收集器仍然可以通过并发的方式让java程序继续执行。
2.分代收集:与其他收集器一样,分代的概率在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不用的方式去处理新建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
3.空间整合:与CMS的“标记-清理”算法不同,G1从整体看来是基于“标记-整理”,从局部(两个Region)看是基于“复制”算法实现的,但是无论如何,这两种算法都意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存。这种有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
4.可预测的停顿:这是G1相对于CMS的另一大优势,降低停顿时间时G1和CMS共同的关注点,但G1除了追求低停顿外,还能建立可预测的停顿时间模型,能然使用者明确指定一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒,这几乎已经是java的垃圾收集器的特征了。
使用G1收集器时,java堆的内存布局就与其他收集器由很大差别,它将整个java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和来年代的概率,但新生代和老年代不是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
G1收集器之所以能建立可预测的停顿时间模型,是因此它可以有计划地避免在整个java堆中进行全区的垃圾收集。G1跟踪各个Region里面的垃圾堆的价值大小(回收所获得得空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式,保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
G1把内存“化整为零”,Region不可能是孤立的。一个对象分配在某个Region中,它并非只能被本Region中的其他对象引用,而是可以与整个java堆任意对象发生引用关系。在G1收集器中,Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用,虚拟机都是使用Remembered Set来避免全堆扫描。G1中每一个Region都有一个与之对应的Remembered Set,虚拟机发现程序在Reference类型的数据进行写操作时,会产生一个Write Barrier暂时中断写操作,检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象),如果时,便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时,在GC根节点的枚举范围中加入Remembered Set即可保证不会堆全堆扫描也不会有遗漏。
如果不计算维护Remembered Set的操作,G1收集器可以大致划分为以下几个步骤:
1.初始标记(Initial Marking)
2.并发标记(Concurrent Marking)
3.最终标记(Final Marking)
4.筛选回收(Live Data Counting and Evacuation)
初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象,并且修改TAMS(Next at Mark Start)的值,让下一阶段用户程序并发运行时,能够在正确可用的Region中创建新对象,这个阶段需要停顿线程,但耗时很短。
并发标记阶段是从GC Roots开始对堆中对象进行可达性分析,找出存活的对象,这个阶段耗时较长,但是可以与用户线程并发执行。
最终标记阶段则是为了修正在并发标记阶段期间因用户吸纳从继续运作而导致标记发生变化的那一部分记录,虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面,最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中,这阶段需要停顿线程,但是可以并行执行。
最后在筛选回收阶段首先堆各个Region的回收价值和成本进行排序,根据用户所期望的GC停顿时间来制定回收计划。这个阶段其实也可以做到与用户程序并发执行,但是因为只回收一部分Region,时间是用户控制的,而且停顿用户线程将大幅提高收集效率。
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值