java 全局变量 内存不回收_jvm大局观之内存管理篇(四):分代假说之下的java垃圾回收算法...

前言

本篇是java内存区域管理系列教程之一 java内存区域的垃圾清理, 教程全系列内容如下

1.java内存区域的划分

2.如何向java内存区域存值

3.java如何判断内存区域中的哪些对象该被回收

4.java内存区域的垃圾清理

5.java内存区域的垃圾清理器

6.低延时垃圾收集器-Shenandoah

今天我们谈谈java如何回收这些垃圾对象.

概括说来,就是 基于分代理论,将堆内存中的垃圾对象,进一步划归到不同区域,然后针对不同的区域,使用针对性的垃圾回收算法

看完本篇文章,读者将能够解答以下问题

1.JVM的常见垃圾回收算法有哪些?

2.简单说一下java的垃圾回收机制。

3.为什么要使用分代回收机制?

4.简述分代垃圾回收器是怎么工作的?

笔墨不易,赠人玫瑰,手留余香

e88368c84835e3be34e376e956a9736e.png

正文

5808cb31a11cacb47bfd01de9f6f4d88.png
关于分区思想, 在后两章的低延时垃圾收集器 Shenandoah中会说到

从如何判定对象消亡的角度出发,垃圾收集算法可以划分为“引用计数式垃圾收集”(Reference Counting GC)和“追踪式垃圾收集”(Tracing GC)两大类

这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。

由于引用计数式垃圾收集算法在主流Java虚拟机中均未涉及,所以我们暂不把它作为正文主要内容来讲解,本篇介绍的所有算法均属于追踪式垃圾收集的范畴

一. 分代收集理论

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

值得注意的是, 分代收集理论也有其缺陷, 最新出现 (或在实验中) 的几款垃圾收集器都展现出了面向全区域收集设计的思想, 或者可以支持全区域不分代的收集的工作模式

1)弱分代假说 (Weak Generational Hypothesis):

绝大多数对象都是朝生夕灭的。

2)强分代假说 (Strong Generational Hypothesis):

熬过越多次垃圾收集过程的对象就越难以消亡。

这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则

收集器应该将Java堆划分出不同的区域,然后将回收对象依据其年龄分配到不同的区域之中存储。

年龄即对象熬过垃圾收集过程的次数

1.如果一个区域中大多数对象都是朝生夕灭,难以熬过垃圾收集过程的话,那 么把它们集中放在一起,每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对 象,就能以较低代价回收到大量的空间 --- 年轻代

2.如果剩下的都是难以消亡的对象,那把它们集中放在一块, 虚拟机便可以使用较低的频率来回收这个区域,这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。 --- 老年代

在Java堆划分出不同的区域之后,垃圾收集器才可以每次只回收其中某一个或者某些部分的区域 ——因而才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分;

也才能够针对不同的区域来安排与里面存储对象存亡特征相匹配的垃圾收集算法——因而发展出了“标记-复制算法”“标记-清除算 法”“标记-压缩算法”等针对性的垃圾收集算法。

这里笔者提前提及了一些新的名词,它们都是本文的重要角色,稍后都会逐一登场,现在读者只需要知道,这一切的出现都始于分代收集理论。

把分代收集理论具体放到现在的商用Java虚拟机里,设计者一般至少会把Java堆划分为新生代(Young Generation)和老年代(Old Generation)两个区域

顾名思义,在新生代中,每次垃圾收集时都发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放


分代收集下的跨代引用问题

对象不是孤立的,对象之间会存在跨代引用。

9b84b90e41d867c0d1cb1223cb6a5828.png
假如只局限于新生代的收集,那么我们将错误的回收E;若想正确回收,那就需要对老年区同样做一次GC搜索,明显效率低下。

假如要现在进行一次只局限于新生代区域内的收集(Minor GC),但新生代中的对象是完全有可能被老年代所引用的,为了找出该区域中的存活对象,不得不在固定的GC Roots之外,再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性,反过来也是一样 。遍历整个老年代所有对象 的方案虽然理论上可行,但无疑会为内存回收带来很大的性能负担。为了解决这个问题,就需要对分代收集理论添加第三条经验法则:

3)跨代引用假说(Intergenerational Reference Hypothesis):

跨代引用相对于同代引用来说仅占极少数。

这其实是可根据前两条假说逻辑推理得出的隐含推论

存在互相引用关系的两个对象,是应该倾向于同时生存或者同时消亡的

举个例子,如果某个新生代对象存在跨代引用,由于老年代对象难以消亡,该引用会使得新生代对象在收集时同样得以存活,进而在年龄增长之后晋升到老年代中,这时 跨代引用也随即被消除了。

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

注意: 刚才我们已经提到了“Minor GC”,后续文中还会出现其他针对不同分代的类似名词, 为避免读者产生混淆,在这里统一定义:

·部分收集(Partial GC):指目标不是完整收集整个Java堆的垃圾收集

其中又分为:

新生代收集(Minor GC/Young GC):指目标只是新生代的垃圾收集。

老年代收集(Major GC/Old GC):指目标只是老年代的垃圾收集。

目前只有CMS收集器会有单独收集老年代的行为。

另外请注意“Major GC”这个说法现在有点混淆,在不同资料上常有不同所指, 读者需按上下文区分到底是指老年代的收集还是整堆收集。

混合收集(Mixed GC):指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。

整堆收集(Full GC):收集整个Java堆和方法区的垃圾收集。

二. 标记-清除算法(Mark-Sweep)

最早出现也是最基础的垃圾收集算法是“标记-清除”(Mark-Sweep)算法,在1960年由Lisp之父 John McCarthy所提出。

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

标记过程就是对象是否属于垃圾的判定过程,这在前一篇讲述垃圾对象标记 判定算法时其实已经介绍过了。

https://zhuanlan.zhihu.com/p/258366363​zhuanlan.zhihu.com

之所以说它(标记-清除)是最基础的收集算法,是因为后续的收集算法大多都是以标记-清除算法为基础,对其缺点进行改进而得到的

它的主要缺点有两个

第一个是执行效率不稳定,如果Java堆中包含大量对 象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除的动作,导致标记和清除两个过 程的执行效率都随对象数量增长而降低;

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

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

267ae8ec90b7c0a823d5e6d8ab7dd894.png

三. 标记-复制算法(Copying)

很重要的算法,几乎所有的垃圾收集器都在使用的算法,包括目前前沿的Shenandoah

1.空间利用率为50%的初级形态

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

为了解决标记-清除算法面对大量可回收对象时执行效率低 的问题,1969年Fenichel提出了一种称为“半区复制”(Semispace Copying)的垃圾收集算法,它将可用 内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存用完了,就将还存活着 的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存 活的,这种算法将会产生大量的内存间复制的开销,但对于多数对象都是可回收的情况,算法需要复 制的就是占少数的存活对象,而且每次都是针对整个半区进行内存回收,分配内存时也就不用考虑有 空间碎片的复杂情况,只要移动堆顶指针,按顺序分配即可。这样实现简单,运行高效,不过其缺陷 也显而易见这种复制回收算法的代价是将可用内存缩小为了原来的一半,空间浪费未免太多了一 点。如下图所示,r1和r2作为GC Root对象,经过可达性分析后,标记除黄色对象为垃圾对象。

120eca6f2efdfd12ff3d70a52692e47e.png

复制过程如下,GC会将五个存活对象复制到to区,并且保证在to区内存空间上的连续性。

030058e5e0c9f618d3356133c32935e8.png

最后,将from区中的垃圾对象清除。

7c08d7fc0ed4859f858dc1445cb44d09.png

2.空间利用率为90%的优化形态

现在的商用Java虚拟机大多都优先采用了这种收集算法去回收新生代,IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此 并不需要按照1∶1的比例来划分新生代的内存空间。

在1989年,Andrew Appel针对具备“朝生夕灭”特点的对象,提出了一种更优化的半区复制分代策 略,现在称为“Appel式回收”。HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局 。

Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的 Survivor空间,每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时,将Eden和Survivor中仍 然存活的对象一次性复制到另外一块Survivor空间上,然后直接清理掉Eden和已用过的那块Survivor空间, 更为详细的过程如下

  1. 首先,Eden区最大,对外提供堆内存。当 Eden 区快要满了,则进行 Minor GC,把存活对象放入Survivor A区,清空 Eden 区;
  2. Eden区被清空后,继续对外提供堆内存;
  3. 当Eden区再次被填满,此时对Eden区和Survivor A区同时进行 Minor GC,把存活对象放入Survivor B区,同时清空Eden 区和Survivor A区;
  4. Eden区继续对外提供堆内存,并重复上述过程,即在Eden区填满后,把Eden区和某个Survivor区的存活对象放到另一个Survivor区;
  5. 当某个Survivor区被填满,且仍有对象未被复制完毕时(后面会提到的分配担保机制),或者某些对象在反复Survive 15 次左右时,则把这部分剩余对象放到Old区;
扩展: 为什么复制15次(15岁)后,被判定为高龄对象,晋升到老年代呢? 因为每个对象的年龄是存在对象头中的,对象头用4bit存储了这个年龄数,而4bit最大可以表示十进制的15,所以是15岁。
有几种情况,对象会晋升到老年代: 1. 超大对象会直接进入到老年代(受虚拟机参数-XX:PretenureSizeThreshold参数影响,默认值0,即不开启,单位为Byte,例如:3145728=3M,那么超过3M的对象,会直接晋升老年代) 2. 如果to区已满,多出来的对象也会直接晋升老年代; 3. 复制15次(15岁)后,依然存活的对象,也会进入老年代

HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1,也即每次新生代中可用内存空间为整个新生代容量的90%(Eden的80%加上一个Survivor的10%),只有一个Survivor空间,即10%的新生代是会 被“浪费”的。

简易图解如下

1.我们有以下的这样的一块java堆,其中的灰色Survivor区为激活状态

9f9f7156370b4e523343512bf939eb69.png

2. 标记GC Roots可达对象(蓝色标记)

5bd495c4139b2c0eaef2aba775f0f5d6.png

3.将标记对象全部复制到另一块Survivor区

77c366f9aef9862e8ca79f42241419a5.png

4.清理掉Eden区和激活的Survivor区中的所有对象,然后交换两个区域的激活状态

e4d5ff0cb40faeb29dd59fa3ee7e40fa.png

分配担保机制

当然,98%的对象可被回收仅仅是“普通场景”下测得的数据,任何人都没有办法百分百 保证每次回收都只有不多于10%的对象存活,因此Appel式回收还有一个充当罕见情况的“逃生门”的安 全设计,当Survivor空间不足以容纳一次Minor GC之后存活的对象时,就需要依赖其他内存区域(实 际上大多就是老年代)进行分配担保(Handle Promotion)

内存的分配担保好比我们去银行借款,如果我们信誉很好,在98%的情况下都能按时偿还,于是 银行可能会默认我们下一次也能按时按量地偿还贷款,只需要有一个担保人能保证如果我不能还款 时,可以从他的账户扣钱,那银行就认为没有什么风险了。内存的分配担保也一样,如果另外一块 Survivor空间没有足够空间存放上一次新生代收集下来的存活对象,这些对象便将通过分配担保机制直 接进入老年代,这对虚拟机来说就是安全的。

带有分配担保机制的标记复制中的Minor GC

在发生Minor GC之前,虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 Minor GC,否则将进行Full GC


扩展1 - JDK 6 Update 24 以前的分配担保机制

但是在JDK 6 Update 24 以前,运行流程如下

在发生Minor GC之前,虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间

如果这个条件成立,那这一次Minor GC可以确保是安全的。

如果不成立,则虚拟机会先查看XX:HandlePromotionFailure参数的设置值是否允许担保失败(Handle Promotion Failure);

如果允许,那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,

如果大于,将尝试进行一次Minor GC,尽管这次Minor GC是有风险的(minorGC如果失败,还需要再一次的Full GC);

如果小于或者-XX:HandlePromotionFailure设置不允许冒险,那这时就要改为进行一次Full GC。

虽然担保失败时绕的圈子是最大的,但通常情况下 都还是会将-XX:HandlePromotionFailure开关打开,避免Full GC过于频繁

扩展1结束分割线


三. 标记-压缩算法(Mark-Compact)

又叫做标记整理,compact: 压缩

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

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

c262555f89c7f687e5e83f6b98f4dd2a.png

总体说来可以看作三步:

1.标记垃圾对象

2.内存碎片整理

3.清除垃圾区域

如下图所示:

1.首先标记垃圾对象(红色)

0865b3a417fa31bcbb26c96d8a6d0054.png

2.内存碎片整理

1634c36e771697c2efa30c57c4fd5840.png

3.内存清理

1f620c43fda7300ac3b6ebf89d5a4479.png

标记-清除算法与标记-压缩算法的本质差异在于前者是一种非移动式的回收算法,而后者是移动式的。

是否移动回收后的存活对象是一项优缺点并存的风险决策:

如果移动存活对象,尤其是在老年代这种每次回收都有大量对象存活区域,移动存活对象并更新 所有引用这些对象的地方将会是一种极为负重的操作,而且这种对象移动操作必须全程暂停用户应用程序才能进行,这就更加让使用者不得不小心翼翼地权衡其弊端了,像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”.

如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话,弥散于堆中的存活对象导致的 空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。

譬如通过“分区空闲分配链表”来解决内存分配问题(计算机硬盘存储大文件就不要求物理连续的磁盘空间,能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的)。内存的访问是用户程序最频繁的操作,甚至都没有之 一,假如在这个环节上增加了额外的负担,势必会直接影响应用程序的吞吐量。

基于以上两点,是否移动对象都存在弊端,移动则内存回收时会更复杂,不移动则内存分配时会更复杂

从垃圾收集的停顿时间来看,不移动对象停顿时间会更短,甚至可以不需要停顿,但是从整个程序的吞吐量来看,移动对象会更划算。

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

即使不移动对象会使得收集器的效率提升一些,但因内存分配和访问相比垃圾收集频率要高得多,这部分的耗时增加,总吞吐量仍然是下降的

即对象的访问的频率远远高于对象被创建分配的频率

HotSpot虚拟机里面关注吞吐量的Parallel Scavenge收集器是基于标记-压缩算法的,而关注延迟的CMS收集器则是基于标记-清除算法的,这也从侧面印证这点。

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

四. 分代算法

分代算法基于复制算法和标记压缩算法或者标记清除算法。
首先,标记清除算法、复制算法、标记压缩算法都有各自的缺点,如果单独用其中某一算法来做GC,会有很大的问题。
例如,标记清除算法会产生大量的内存碎片,复制算法会损失部分的内存,标记压缩算法的碎片整理会造成较大的局部延时消耗。
其次,复制算法和标记压缩算法都有各自适合的使用场景。复制算法适用于每次回收时,存活对象少的场景(年轻代),这样就会减少复制量标记压缩算法适用于回收时,存活对象多的场景(老年代),这样就会减少内存碎片的产生,碎片整理的代价就会小很多


分代算法将内存区域分为两部分:新生代和老年代。
根据新生代和老年代中对象的不同特点,使用不同的GC算法。

新生代对象的特点是:创建出来没多久就可以被回收(例如虚拟机栈中创建的对象,方法出栈就会销毁)。也就是说,每次回收时,只有小部分存活对象,所以新生代适用于复制算法

老年代的特点是:经过多次GC,依然存活。也就是说,每次GC时,大部分是存活对象,所以老年代适用于标记压缩算法

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值