Java 对象之死

我们都知道垃圾回收是指回收那些不再使用的对象所占的内存区域。生动的说,在 Java 的世界里,无用的人就要拉出去枪毙了,并且把其所占的地盘清理,以便让“别人“来使用。

《Java 对象之死》 Java对象之死

如何判断对象“无用”?

关于判断对象是否无用的算法,在JVM的发展过程中出现过两种算法:一种是引用计数和根集算法。

引用计数算法

例如下图中的object1的引用计数是2,GC的时候不回收,object6、object7引用计数为0,GC的时候要被回收。引用计数有个缺点:当引用产生闭环的时候即便是对象实际上已经“无用”也无法回收了,例如下图中的 ,object4、object5、object8直接引用关系。

《Java 对象之死》 引用计数算法

根集算法

引用计数算法简高效,早期的 Java 虚拟机中使用这个方式,但是正如上面提到的不能解决“引用闭环”的问题,后来的 Java 虚拟机中普普采用根集算法。从 GCRoot(比如一个静态变量) 开始遍历引用关系,能遍历到的,叫做引用可达,遍历不到的叫做不可达。不可达的对象就被判“死刑了”,GC的时候将被枪毙掉。

《Java 对象之死》 根集算法

对象回收之后的内存如何处置?

人死了、遗产处理不好会产生很多纠纷,所以有法律制度。在 JVM 的世界里对象死了,剩下的“遗产”无非就是它占据的那片内存空间。对象死后生下的那部分内存空间进行一下规划的,具体算法有三种。

《Java 对象之死》 三种回收算法.png

标记-清除

标记就是把那些“无用的对象”标记一下,被标记的对象等于被判了死刑,也就是就可以回收了,清除就是变那些被标记了的对象清楚掉。

《Java 对象之死》 GC标记之后的状态
《Java 对象之死》 清除之后的状态

我们发现,清除之后的状态,其中的可用内存并不是连续的,也就是说内存存在碎片,如果创建一个大对象,无法分配到足够大的连续内存空间,使得GC不得不做一次重新整理。由于可用对象和无用对象直接的内存不是连续的,所以标记的过程是要遍历识别内存区域的,清除的过程也是要遍历识别的,整个过程效率比较低。

标记-复制

标记的过程不变。把内存划分为两部分,一部分叫做预留区域(下图虚线框中),不分配对象。在GC的时候把那些正在使用的对象复制到预留区域,然后再把非预留区域以外的内存全部清除。

《Java 对象之死》 标记之后内存状态
《Java 对象之死》 复制之后内存状态
《Java 对象之死》 清除之后内存状体

解决了效率和内存碎片的问题,但是代价是昂贵的:牺牲了1/2的内存,显然在很多情况下是无法接受的。

标记-整理

标记的过程依然不变,标记之后处于内存末端区域的正在使用的对象向前移动占据覆盖那些被标记了的区域(有一种碾压的感觉),把正在使用的对象赶到一起,再把剩余的标记对象全部清除。

《Java 对象之死》 标记之后内存状体
《Java 对象之死》 移动之后的内存状态
《Java 对象之死》 清除之后内存状体

分代混合算法

在现代虚拟机(通常就是 HotSpot(TM)),使用的分代算法来处理内存,并没有什么新意,只是针对对象的生命周期范围来划分区域,不同的区域使用不同的算法。一般分为新生代和老生代,新生代由于生命不长,GC的时候大部分对象已经死亡,所以有足够的空间作为担保,可用使用标记-复制算法,对于老生代老生代使用标记-清除或标记-整理算法。

《Java 对象之死》 分代混合算法

Stop the world

《Java 对象之死》 抬脚打扫卫生.png

想象一下,你不可能在妈妈一边打扫卫生的时候你一边扔垃圾吧,她当然希望你乖乖做在沙发上抬起脚来别动。JVM的世界亦如此,前面我们说道使用引用关系的根集算法来标记对象是否无用,二这个引用关系只是某一时刻的“快照”,使用一个叫做OopMap的数据结构来保存的。引用关系是会随时间变化的,所以在垃圾回收器进行垃圾回收时候就必须的有所停顿,sun把这个现象叫做“Stop the world ”。

所以频繁的GC会影响性能,对象存活时间过长会占用内存,在实际开发过程中我们如何去平衡内存空间和执行效率、如何去选择对象生命周期是非常重要的。

    原文作者:大利猫
    原文地址: https://www.jianshu.com/p/73d8d6c54515
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞