JVM--垃圾回收器,极其重要

停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序,良好的响应速度能提升用户体验。而高吞吐量则可以最高效率地利用处理器资源,尽快完成程序的运算任务, 主要适合在后台运算而不需要太多交互的分析任务。

Parallel Scavenge 收集器还有一个参数,当这个参数被激活之后,就不需要人工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象大小等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

这种调节方式称为垃圾收集的「自适应的调节策略」,这种策略也是 Parallel Scavenge 收集器区别于 ParNew 收集器的一个重要特性。

关键词:新生代、多线程、标记复制、 吞吐量、自适应调节。

五、Serial Old 收集器

===================================================================================

Serial Old 是Serial 收集器的「老年代版本」,它同样是一个「单线程」收集器,使用「标记-整理」算法,这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。

在这里插入图片描述

关键词:老年代、单线程、标记整理。

六、Parallel Old 收集器

=====================================================================================

Parallel Old 是 Parallel Scavenge 收集器的「老年代版本」,支持多线程并发收集,基于「标记-整理」算法实现。直到 Parallel Old 收集器出现后,“吞吐量优先” 收集器终于有了比较名副其实的搭配组合, 在注重吞吐量或者处理器资源较为稀缺的场合,都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器这个组合。

Parallel Scavenge / Parallel Old 收集器运行示意图:

在这里插入图片描述

关键词:老年代、 多线程、标记整理。

七、CMS收集器

===========================================================================

CMS(Concurrent Mark Sweep)收集器是一种以「获取最短回收停顿时间」为目标的收集器,从名字上就可以看出 CMS 收集器是基于「标记-清除」算法实现的。

它的运作过程相对于前面几种收集器来说要更复杂一些,整个过程分为四个步骤,包括: 「初始标记、并发标记、重新标记、并发清除」。 其中「初始标记、重新标记」这两个步骤仍然需要「Stop The World」。

CMS 的收集过程如下:

在这里插入图片描述

  1. 初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象,速度很快。

  2. 并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。

  3. 重新标记阶段则是为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录, 这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。

  4. 并发清理阶段,清理删除掉标记阶段判断的已经死亡的对象,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。

CMS是一款优秀的收集器,它最主要的优点在名字上已经体现出来:并发收集、低停顿,一些官方

公开文档里面也称之为「并发低停顿收集器」。 CMS收集器是HotSpot虚拟机追求低停顿的第一次成功尝试,但是它还远达不到完美的程度,至少有以下三个明显的缺点:

  1. 并发阶段,虽然不会导致用户线程停顿,却因为占用一部分线程而导致应用程序变慢,「降低总吞吐量」。

  2. 它无法处理「浮动垃圾」,有可能会出现并发失败进而导致另一次Full GC的发生。

  3. 它是一款基于「标记清除」算法实现的收集器,这意味着收集结束时会有大量「空间碎片」产生。

什么是浮动垃圾?

在CMS的「并发标记和并发清理」阶段,用户线程是还在继续运行的,程序在运行自然就还会伴随有新的垃圾对象不断产生,但这一部分垃圾对象是出现在标记过程结束以后, CMS无法在当次收集中处理掉它们,只好留待下一次垃圾收集时再清理掉。 这一部分垃圾就称为“浮动垃圾”。

什么是并发失败?

由于在垃圾收集阶段用户线程还需要持续运行,那就还需要预留足够内存空间提供给用户线程使用,因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集,必须预留一部分空间供并发收集时的程序运作使用。

到了JDK 6时,CMS收集器的启动阈值就已经提升至92%。但这更容易面临另一种风险: 要是CMS运行期间预留的内存无法满足程序分配新对象的需要,就会出现一次「并发失败」, 这时候虚拟机将不得不启动后备预案:冻结用户线程的执行,临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。

关键词:老年代、低停顿、标记清除、 3标记1清除。

八、G1 收集器 (Garbage First)

===========================================================================================

Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果,为什么说它是里程碑呢?因为 G1 这个收集器是一种面向局部的垃圾收集器,HotSpot 团队开发这个垃圾收集器为了让它替换掉 CMS 收集器,所以到后来, 直到 JDK 9 发布之日, G1宣告取代 Parallel Scavenge 加 Parallel Old 组合,成为服务端模式下的默认垃圾收集器,而 CMS 则沦落至被声明为不推荐使用的收集器。

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

G1也仍是「遵循分代收集理论」设计的,但其堆内存的布局与其他收集器有非常明显的差异: G1不再坚持固定大小以及固定数量的分代区域划分,而是把连续的Java堆划分为多个大小相等的「独立区域(Region)」,每一个Region都可以根据需要,扮演新生代的 Eden空间、 Survivor空间,或者老年代空间。

此外, 还有一类专门用来存储大对象的特殊区域(Humongous Region)。它是专门用来存储大对象的,G1 认为只要大小超过了 Region 容量一半的对象即可判定为大对象。如果超过了 Region 容量的大对象,将会存储在连续的 Humongous Region 中,G1 大多数行为都会吧 Humongous Region 作为老年代来看待。

G1 保留了新生代(Eden Suvivor)和老年代的概念,但是新生代和老年代不再是固定的了。它们都是一系列区域的动态集合。

更具体的处理思路是,让G1收集器去跟踪各个Region里面的垃圾堆积的「价值」大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一个优先级列表,每次根据用户设定允许的收集停顿时间(默认是200毫秒), 优先处理回收价值收益最大的那些Region,这也就是「Garbage First」名字的由来。

G1 收集器的运作过程可以分为以下四步:

  1. 「初始标记」:这个步骤也仅仅是标记一下 GC Roots 能够直接关联到的对象;并修改 TAMS 指针的值(每一个 Region 都有两个 RAMS 指针),让下一阶段用户并发运行时,能够在可用的 Region 中分配对象,这个阶段需要暂停用户线程,但是时间很短。这个停顿是借用 Minor GC 的时候完成的,耗时很短。

  2. 「并发标记」:从 GC Root 开始对堆中对象进行可达性分析,递归扫描整个堆中的对象图,找出要回收的对象,这阶段耗时较长,但可与用户程序并发执行。当对象图扫描完成后,重新处理 SATB 记录下的在并发时有引用的对象;

  3. 「最终标记」:对用户线程做一个短暂的暂停,用于处理并发阶段结束后遗留下来的少量 SATB 记录(一种原始快照,用来记录并发标记中某些对象)

  4. 「筛选回收」:负责更新 Region 的统计数据,对各个 Region 的回收价值和成本进行排序,根据用户所期望的停顿时间来制定回收计划,可以自由选择多个 Region 构成回收集,然后把决定要回收的那一部分 Region 存活对象复制到空的 Region 中,再清理掉整个旧 Region 的全部空间。这里的操作设计对象的移动,所以必须要暂停用户线程,由多条收集器线程并行收集。

从上面这几个步骤可以看出,除了并发标记外,其余三个阶段都需要暂停用户线程,所以,这个 G1 收集器并非追求低延迟,官方给出的设计目标是在延迟可控的情况下尽可能的提高吞吐量,担任全功能收集器的重任。

下面是 G1 回收的示意图:

在这里插入图片描述

G1 收集器同样也有缺点和问题:

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

G1 收集器使用 记忆集 避免全堆作为 GC Roots 扫描。但在 G1 收集器上记忆集的实现其实要复杂很多。

它的每个 Region 都维护有自己的记忆集, 这些记忆集会记录下别的 Region 指向自己的指针,并标记这些指针分别在哪些卡页的范围之内。

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
img
img
img
img
img
img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新

如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Java)
img

最后

小编精心为大家准备了一手资料

以上Java高级架构资料、源码、笔记、视频。Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术

【附】架构书籍

  1. BAT面试的20道高频数据库问题解析
  2. Java面试宝典
  3. Netty实战
  4. 算法

BATJ面试要点及Java架构师进阶资料

ookeeper、Spring cloud、分布式、高并发等架构技术

【附】架构书籍

  1. BAT面试的20道高频数据库问题解析
  2. Java面试宝典
  3. Netty实战
  4. 算法

[外链图片转存中…(img-WWdal6tj-1711759049252)]

BATJ面试要点及Java架构师进阶资料

[外链图片转存中…(img-Ey5tpojb-1711759049253)]

  • 24
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值