草庐IT

JVM的垃圾收集算法

飞鱼的博客 2023-04-10 原文

介绍分代收集理论和几种垃圾收集算法的思想及其发展过程。

分代收集理论

当前商业虚拟机的垃圾收集器,大多数都遵循了 “分代收集”(Generational Collection)的理论进行设计,分代收集名为理论,实质是一套符合大多数程序运行实际情况的经验法则,分代收集理论它建立在两个分代假说之上:

  • 弱分代假说(Weak Generational Hypothesis):绝大多数对象都是朝生夕灭的。
  • 强分代假说(Strong Generational Hypothesis):熬过越多次垃圾收集过程的对象就越难以消亡。

这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则:垃圾收集器应该将 Java 堆划分出不同的区域,然后将回收对象依据其年龄(年龄即对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。显而易见:

  • 如果一个区域中大多数对象都是朝生夕灭,难以熬过垃圾收集过程的话,那么把它们集中放在一起,每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象,就能以较低的代价回收到大量的空间;
  • 如果剩下的都是难以消亡的对象,那把它们集中放在一起,虚拟机便可以使用较低的频率来回收这个区域。
  • 这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。

在 Java 堆划分出不同的区域之后,垃圾收集器才可以每次只回收其中某一个或者某些部分的区域,因而才有了 “Minor GC”、“Major GC”、“Full GC” 这样的回收类型的划分;也才能够针对不同的区域 安排与里面存储对象存亡特征相匹配的垃圾收集算法,因而发展出了 “标记-清除算法”、“标记-复制算法”、“标记-整理算法” 等针对性的垃圾收集算法。

把分代收集理论具体放到现在的商用 Java 虚拟机里,设计者一般至少会把 Java 堆划分为新生代(Young Generation) 和老年代(Old Generation)两个区域。顾名思义,在新生代中,每次垃圾收集时都会发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放。


分代收集并非只是简单划分一下内存区域那么容易,它至少存在一个明显的困难:对象不是孤立的,对象之间会存在跨代引用。假如现在要进行一次只局限于新生代区域内的垃圾收集(Minor GC),但新生代中的对象是完全有可能被老年代所引用的,为了找出该区域中的存活对象,不得不在固定的 GC Roots 之外,再额外遍历整个老年代中所有的对象来确保可达性分析结果的正确性,反过来也是一样。

遍历整个老年代中所有对象的方案虽然理论上可行,但无疑会为内存回收带来很大的性能负担。为了解决这个问题,就需要对分代收集理论添加第三条经验法则:跨代引用假说(Intergenerational Reference Hypothesis):跨代引用相对于同代引用来说仅占极少数。

这其实是可根据前两条假说逻辑推理得出的隐含推论:存在互相引用关系的两个对象,是应该倾向于同时生存或者同时消亡的。举个例子,如果某个新生代对象存在跨代引用,由于老年代对象难以消亡,该引用会使得新生代对象在垃圾收集时同样得以存活,进而在年龄增长之后晋升到老年代中,这时跨代引用也随即被消除了。

依据这条假说,我们就不应再为了少量的跨代引用去扫描整个老年代,也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用,只需在新生代上建立一个全局的数据结构(该结构被称为“记忆集”, Remembered Set),这个结构把老年代划分成若干小块,标识出老年代的哪一块内存会存在跨代引用。此后当发生 Minor GC 时,只有包含了跨代引用的小块内存里的对象才会被加入到 GC Roots 进行扫描。虽然这种方法需要在对象改变引用关系(如将自己或者某个属性赋值)时维护记录数据的正确性,会增加一些运行时的开销,但比起垃圾收集时扫描整个老年代来说仍然是划算的。

标记-清除算法

最早出现也是最基础的垃圾收集算法是 “标记-清除”(Mark-Sweep)算法,“标记-清除” 算法分为 “标记” 和 “清除” 两个阶段:首先标记出所有需要回收的对象,在标记完成后,统一回收掉所有被标记的对象。也可以反过来,标记出所有存活的对象,在标记完成后,统一回收掉所有未被标记的对象。


之所以说 “标记-清除” 算法是最基础的收集算法,是因为后续的垃圾收集算法大多是以 “标记-清除” 算法为基础,对 “标记-清除” 算法的缺点进行改进而得到的。“标记-清除” 算法的主要缺点有两个:

  • 第一个是:执行效率不稳定。如果 Java 堆中包含大量的对象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除的动作,导致标记和清除这两个过程的执行效率都随对象数量增长而降低;
  • 第二个是:内存空间的碎片化问题。标记、清除之后会产生大量不连续的内存碎片,内存碎片太多可能会导致程序运行的过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

“标记-清除” 算法的执行过程如图所示。

标记-复制算法

“标记-复制” 算法常被简称为复制算法。

为了解决 “标记-清除” 算法面对大量可回收对象时执行效率低的问题,1969 年 Fenichel 提出了一种被称为 “半区复制”(Semispace Copying)的垃圾收集算法,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块内存用完时,就将还存活着的对象复制到另外一块内存上,然后再将已使用过的内存空间一次清理掉。


“标记-复制” 算法的优劣局限:

  • 如果内存中多数对象都是存活的,“标记-复制” 算法将会产生大量的内存间复制的开销,但对于多数对象都是可回收的情况,算法需要复制的就是占少数的存活对象,而且每次都是针对整个半区进行内存回收,分配内存时也就不用考虑有空间碎片的复杂情况,只要移动堆顶指针,按顺序分配即可。
  • “标记-复制” 算法的实现简单,运行高效,不过其缺陷也显而易见,“标记-复制” 算法的代价是将可用内存缩小为了原来的一半,空间浪费有点多。

“标记-复制” 算法的执行过程如图所示。

标记-整理算法

“标记-复制” 算法在对象存活率较高时就要进行较多的复制操作,效率将会降低。更关键的是,如果不想浪费 50% 的空间,就需要有额外的空间进行分配担保,以应对被使用的内存中所有对象都 100% 存活的极端情况,所以在老年代一般不能直接选用 “标记-复制” 算法。

针对老年代对象的存亡特征,1974 年 Edward Lueders 提出了一种有针对性的 “标记-整理”(Mark-Compact)算法, “标记-整理” 算法的标记过程仍然与 “标记-清除” 算法一样,但后续的步骤不是直接对可回收对象进行清理, 而是让所有存活的对象都向内存空间的一端移动,然后直接清理掉边界以外的内存。


“标记-整理” 算法的执行过程如图所示。


“标记-清除” 算法与 “标记-整理” 算法的本质差异在于 “标记-清除” 算法是一种非移动式的回收算法,而 “标记-整理” 算法是一种移动式的回收算法。是否移动回收后的存活对象是一项优缺点并存的风险决策:

  • 如果移动存活对象,尤其是在老年代这种每次回收都有大量对象存活区域,移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作,而且这种对象移动操作必须全程暂停用户应用程序才能进行,这就更加让使用者不得不小心翼翼地权衡其弊端了,像这样的停顿被最初的虚拟机设计者形象地描述为 “Stop The World”。
  • 但如果跟 “标记-清除” 算法那样完全不考虑移动和整理存活对象的话,弥散于 Java 堆中的存活对象导致的内存碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。譬如通过 “分区空闲分配链表” 来解决内存分配问题(计算机硬盘存储大文件就不要求物理连续的磁盘空间, 能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的) 。内存的访问是用户程序最频繁的操作,甚至都没有之一,假如在内存访问这个环节上增加了额外的负担,势必会直接影响应用程序的吞吐量。

基于以上两点,是否移动对象都存在弊端,移动对象则内存回收时会更复杂,不移动对象则内存分配时会更复杂。从垃圾收集的停顿时间来看,不移动对象停顿时间会更短,甚至可以不需要停顿,但是从整个程序的吞吐量来看,移动对象会更划算。即使不移动对象会使得收集器的效率提升一些, 但因内存分配和访问相比垃圾收集的频率要高得多,这部分的耗时增加,总吞吐量仍然是下降的。HotSpot 虚拟机里面关注吞吐量的 Parallel Scavenge 收集器是基于 “标记-整理” 算法的,而关注延迟的 CMS 收集器则是基于 “标记-清除” 算法的,这也从侧面印证了这一点。

此语境中,吞吐量的实质是赋值器(Mutator,可以理解为使用垃圾收集的用户程序,本书为便于理解,多数地方用 “用户程序” 或 “用户线程” 代替)与收集器的效率总和。

另外, 还有一种 “和稀泥式” 的解决方案可以不在内存分配和访问上增加太大的额外负担,做法是让虚拟机平时多数时间都采用 “标记-清除” 算法,暂时容忍内存碎片的存在,直到内存空间的碎片化程度已经大到影响对象分配时,再采用 “标记-整理” 算法收集一次,以获得规整的内存空间。前面提到的基于 “标记-清除” 算法的 CMS 收集器面临内存碎片过多时采用的就是这种处理办法。

总结

分代收集理论

分代收集理论建立在两个分代假说之上:

  • 弱分代假说(Weak Generational Hypothesis):绝大多数对象都是朝生夕灭的。
  • 强分代假说(Strong Generational Hypothesis):熬过越多次垃圾收集过程的对象就越难以消亡。

这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则:垃圾收集器应该将 Java 堆划分出不同的区域,然后将回收对象依据其年龄(年龄即对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。

在 Java 堆划分出不同的区域之后,垃圾收集器才可以每次只回收其中某一个或者某些部分的区域,因而才有了 “Minor GC”、“Major GC”、“Full GC” 这样的回收类型的划分;也才能够针对不同的区域 安排与里面存储对象存亡特征相匹配的垃圾收集算法,因而发展出了 “标记-清除算法”、“标记-复制算法”、“标记-整理算法” 等针对性的垃圾收集算法。

把分代收集理论具体放到现在的商用 Java 虚拟机里,设计者一般至少会把 Java 堆划分为新生代(Young Generation) 和老年代(Old Generation)两个区域。顾名思义,在新生代中,每次垃圾收集时都会发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放。

垃圾收集算法

“标记-清除” 算法

“标记-清除” 算法分为 “标记” 和 “清除” 两个阶段:首先标记出所有需要回收的对象,在标记完成后,统一回收掉所有被标记的对象。也可以反过来,标记出所有存活的对象,在标记完成后,统一回收掉所有未被标记的对象。

后续的垃圾收集算法大多是以 “标记-清除” 算法为基础,对 “标记-清除” 算法的缺点进行改进而得到的。


“标记-复制” 算法

“标记-清除” 算法在有大量对象需要回收时,要进行大量的清除操作,垃圾收集的效率将会降低。为了解决这个问题,有一个人提出了 “标记-复制” 算法,也被称为 “半区复制”。“标记-复制” 算法将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块内存用完时,就将还存活着的对象复制到另外一块内存上,然后再将已使用过的内存空间一次清理掉。


“标记-整理” 算法

“标记-复制” 算法在对象存活率较高(多数对象都是存活的,几乎没有对象需要回收)时,要进行大量的复制操作,垃圾收集的效率将会降低。为了解决这个问题,有一个人提出了 “标记-整理” 算法, “标记-整理” 算法的标记过程仍然与 “标记-清除” 算法一样,但后续的步骤不是直接对可回收对象进行清理, 而是让所有存活的对象都向内存空间的一端移动,然后直接清理掉边界以外的内存。

不同算法的优劣局限

不同垃圾收集算法的优劣局限。


“标记-清除” 算法的优劣局限:

  • 第一个是:存在内存空间的碎片化问题。标记、清除之后会产生大量不连续的内存碎片,内存碎片太多可能会导致程序运行的过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
  • 第二个是:执行效率不稳定。在有大量对象需要回收时,要进行大量的清除操作,垃圾收集的效率将会降低。

“标记-复制” 算法的优劣局限:

  • 第一个是:不存在内存空间的碎片化问题。当一块内存用完时,就将还存活着的对象复制到另外一块内存上,分配内存时也就不用考虑有空间碎片的复杂情况,只要移动堆顶指针,按顺序分配即可。
  • 第二个是:执行效率不稳定。在对象存活率较高(多数对象都是存活的,几乎没有对象需要回收)时,要进行大量的复制操作,垃圾收集的效率将会降低。
  • 第三个是:空间浪费。“标记-复制” 算法的代价是将可用内存缩小为了原来的一半,空间浪费有点多

“标记-整理” 算法的优劣局限:

  • 第一个是:不存在内存空间的碎片化问题。垃圾收集时,让所有存活的对象都向内存空间的一端移动,然后直接清理掉边界以外的内存,不存在内存空间的碎片化问题。
  • 第二个是:停顿时间较长。垃圾收集时,需要移动存活的对象并更新所有引用这些对象的地方,这种对象移动操作必须全程暂停用户应用程序才能进行,停顿时间较长。

“标记-清除” 算法与 “标记-整理” 算法的本质差异在于 “标记-清除” 算法是一种非移动式的回收算法,而 “标记-整理” 算法是一种移动式的回收算法。是否移动回收后的存活对象是一项优缺点并存的风险决策。

  • 移动回收后的存活对象,不存在内存空间的碎片化问题,但内存回收时会更复杂(需要移动存活的对象并更新所有引用这些对象的地方);
  • 不移动回收后的存活对象,内存回收时的停顿时间会更短,甚至可以不需要停顿,但是内存分配时会更复杂(需要考虑内存空间的碎片化问题)。

参考资料

《深入理解 Java 虚拟机》第 3 章:垃圾收集器与内存分配策略 3.3 垃圾收集算法

有关JVM的垃圾收集算法的更多相关文章

  1. 区块链之加解密算法&数字证书 - 2

    目录一.加解密算法数字签名对称加密DES(DataEncryptionStandard)3DES(TripleDES)AES(AdvancedEncryptionStandard)RSA加密法DSA(DigitalSignatureAlgorithm)ECC(EllipticCurvesCryptography)非对称加密签名与加密过程非对称加密的应用对称加密与非对称加密的结合二.数字证书图解一.加解密算法加密简单而言就是通过一种算法将明文信息转换成密文信息,信息的的接收方能够通过密钥对密文信息进行解密获得明文信息的过程。根据加解密的密钥是否相同,算法可以分为对称加密、非对称加密、对称加密和非

  2. 100个python算法超详细讲解:画直线 - 2

    1.问题描述使用Python的turtle(海龟绘图)模块提供的函数绘制直线。2.问题分析一幅复杂的图形通常都可以由点、直线、三角形、矩形、平行四边形、圆、椭圆和圆弧等基本图形组成。其中的三角形、矩形、平行四边形又可以由直线组成,而直线又是由两个点确定的。我们使用Python的turtle模块所提供的函数来绘制直线。在使用之前我们先介绍一下turtle模块的相关知识点。turtle模块提供面向对象和面向过程两种形式的海龟绘图基本组件。面向对象的接口类如下:1)TurtleScreen类:定义图形窗口作为绘图海龟的运动场。它的构造器需要一个tkinter.Canvas或ScrolledCanva

  3. ruby - 在 Ruby 数组中收集重复项的最快/单行方法? - 2

    像这样转换数组的最快/单行方法是什么:[1,1,1,1,2,2,3,5,5,5,8,13,21,21,21]...进入像这样的对象数组:[{1=>4},{2=>2},{3=>1},{5=>3},{8=>1},{13=>1},{21=>3}] 最佳答案 要获得所需的格式,您可以附加一个调用以映射到您的解决方案:array.inject({}){|h,v|h[v]||=0;h[v]+=1;h}.map{|k,v|{k=>v}}虽然它仍然是单行的,但它开始变得凌乱了。 关于ruby-在Ruby

  4. ruby - 在 Ruby 中实现 Luhn 算法 - 2

    我一直在尝试用Ruby实现Luhn算法。我一直在执行以下步骤:该公式根据其包含的校验位验证数字,该校验位通常附加到部分帐号以生成完整帐号。此帐号必须通过以下测试:从最右边的校验位开始向左移动,每第二个数字的值加倍。将乘积的数字(例如,10=1+0=1、14=1+4=5)与原始数字的未加倍数字相加。如果总模10等于0(如果总和以零结尾),则根据Luhn公式该数字有效;否则无效。http://en.wikipedia.org/wiki/Luhn_algorithm这是我想出的:defvalidCreditCard(cardNumber)sum=0nums=cardNumber.to_s.s

  5. Ruby 斐波那契算法 - 2

    下面是我写的一个计算斐波那契数列中的值的方法:deffib(n)ifn==0return0endifn==1return1endifn>=2returnfib(n-1)+(fib(n-2))endend它工作到n=14,但在那之后我收到一条消息说程序响应时间太长(我正在使用repl.it)。有人知道为什么会这样吗? 最佳答案 Naivefibonacci进行了大量的重复计算-在fib(14)fib(4)中计算了很多次。您可以将内存添加到您的算法中以使其更快:deffib(n,memo={})ifn==0||n==1returnnen

  6. ruby-on-rails - 为什么 Devise/Omniauth 会向 URL 添加垃圾? - 2

    使用facebook登录后,我被重定向到/#_=_,其中显示主页。这种垃圾也出现在其他URL中,例如当注册失败并被重定向到/users/sign_in#_=_为什么会发生这种情况,我该如何解决? 最佳答案 如果你真的不想要它,一些简单的javascript就可以了:if(window.location.hash=="#_=_"){window.location.hash="";} 关于ruby-on-rails-为什么Devise/Omniauth会向URL添加垃圾?,我们在StackO

  7. ruby-on-rails - ActionMailer HTML 编码 hell - 特殊字符替换为垃圾 - 2

    我有UTF-8字符串:Website•Facebook那是中间的一颗子弹又名•或0xE20x800xA2此值已正确存储在数据库中,并使用默认设置使用Rails3和ruby​​1.9.3正确显示在屏幕上。我正在尝试通过HTML电子邮件发送此邮件,但是当一切都说完之后,接收端看到的是垃圾:这背后的代码很简单,我有一个ActionMailer子类(默认使用UTF-8)设置以在布局中发送带有UTF-8内容编码的HTML电子邮件:email.html.erb布局文件:"all"%>内容使用与呈现网页相同的View,重要的一行是:我已经尝试了很多很多force_encoding的排列,e

  8. ruby-on-rails - Rails add_index 算法 : :concurrently still causes database lock up during migration - 2

    为了防止在迁移到生产站点期间出现数据库事务错误,我们遵循了https://github.com/LendingHome/zero_downtime_migrations中列出的建议。(具体由https://robots.thoughtbot.com/how-to-create-postgres-indexes-concurrently-in概述),但在特别大的表上创建索引期间,即使是索引创建的“并发”方法也会锁定表并导致该表上的任何ActiveRecord创建或更新导致各自的事务失败有PG::InFailedSqlTransaction异常。下面是我们运行Rails4.2(使用Acti

  9. ruby - 趋势算法 - 2

    我正在开发一个类似微论坛的项目,其中一个特殊用户发布一条快速(接近推文大小)的主题消息,订阅者可以用他们自己的类似大小的消息来响应。直截了当,没有任何形式的“挖掘”或投票,只是每个主题消息的响应按时间顺序排列。但预计会有很高的流量。我们想根据它们引起的响应嗡嗡声来标记主题消息,使用0到10的等级。在谷歌上搜索了一段时间的趋势算法和开源社区应用示例,到目前为止已经收集到两个有趣的引用资料,但我还没有完全理解它们:Understandingalgorithmsformeasuringtrends,关于使用基线趋势算法比较维基百科页面浏览量的讨论,在SO上。TheBritneySpearsP

  10. Ruby - 不支持的密码算法 (AES-256-GCM) - 2

    我收到错误:unsupportedcipheralgorithm(AES-256-GCM)(RuntimeError)但我似乎具备所有要求:ruby版本:$ruby--versionruby2.1.2p95OpenSSL会列出gcm:$opensslenc-help2>&1|grepgcm-aes-128-ecb-aes-128-gcm-aes-128-ofb-aes-192-ecb-aes-192-gcm-aes-192-ofb-aes-256-ecb-aes-256-gcm-aes-256-ofbRuby解释器:$irb2.1.2:001>require'openssl';puts

随机推荐