博客
关于我
【转载】Java 对象之死
阅读量:289 次
发布时间:2019-03-01

本文共 1708 字,大约阅读时间需要 5 分钟。

原文链接:http://www.jianshu.com/p/73d8d6c54515

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

Java对象之死

如何判断对象“无用”?

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

引用计数算法

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

引用计数算法

根集算法

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

根集算法

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

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

三种回收算法.png

标记-清除

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

GC标记之后的状态
清除之后的状态

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

标记-复制

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

标记之后内存状态
复制之后内存状态
清除之后内存状体

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

标记-整理

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

标记之后内存状体
移动之后的内存状态
清除之后内存状体

分代混合算法

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

分代混合算法

Stop the world

抬脚打扫卫生.png

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

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

    文/大利猫(简书作者)
    原文链接:http://www.jianshu.com/p/73d8d6c54515
    著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。
    你可能感兴趣的文章
    NHibernate学习[1]
    查看>>
    NHibernate异常:No persister for的解决办法
    查看>>
    Nhibernate的第一个实例
    查看>>
    NHibernate示例
    查看>>
    nid修改oracle11gR2数据库名
    查看>>
    NIFI1.21.0/NIFI1.22.0/NIFI1.24.0/NIFI1.26.0_2024-06-11最新版本安装_采用HTTP方式_搭建集群_实际操作---大数据之Nifi工作笔记0050
    查看>>
    NIFI1.21.0_java.net.SocketException:_Too many open files 打开的文件太多_实际操作---大数据之Nifi工作笔记0051
    查看>>
    NIFI1.21.0_Mysql到Mysql增量CDC同步中_日期类型_以及null数据同步处理补充---大数据之Nifi工作笔记0057
    查看>>
    NIFI1.21.0_Mysql到Mysql增量CDC同步中_补充_插入时如果目标表中已存在该数据则自动改为更新数据_Postgresql_Hbase也适用---大数据之Nifi工作笔记0058
    查看>>
    NIFI1.21.0_Mysql到Mysql增量CDC同步中_补充_更新时如果目标表中不存在记录就改为插入数据_Postgresql_Hbase也适用---大数据之Nifi工作笔记0059
    查看>>
    NIFI1.21.0_NIFI和hadoop蹦了_200G集群磁盘又满了_Jps看不到进程了_Unable to write in /tmp. Aborting----大数据之Nifi工作笔记0052
    查看>>
    NIFI1.21.0_Postgresql和Mysql同时指定库_指定多表_全量同步到Mysql数据库以及Hbase数据库中---大数据之Nifi工作笔记0060
    查看>>
    NIFI1.21.0最新版本安装_连接phoenix_单机版_Https登录_什么都没改换了最新版本的NIFI可以连接了_气人_实现插入数据到Hbase_实际操作---大数据之Nifi工作笔记0050
    查看>>
    NIFI1.21.0最新版本安装_配置使用HTTP登录_默认是用HTTPS登录的_Https登录需要输入用户名密码_HTTP不需要---大数据之Nifi工作笔记0051
    查看>>
    NIFI1.21.0通过Postgresql11的CDC逻辑复制槽实现_指定表多表增量同步_增删改数据分发及删除数据实时同步_通过分页解决变更记录过大问题_02----大数据之Nifi工作笔记0054
    查看>>
    NIFI1.21.0通过Postgresql11的CDC逻辑复制槽实现_指定表多表增量同步_增加修改实时同步_使用JsonPath及自定义Python脚本_03---大数据之Nifi工作笔记0055
    查看>>
    NIFI1.21.0通过Postgresql11的CDC逻辑复制槽实现_指定表多表增量同步_插入修改删除增量数据实时同步_通过分页解决变更记录过大问题_01----大数据之Nifi工作笔记0053
    查看>>
    NIFI1.21.0通过Postgresql11的CDC逻辑复制槽实现_指定表或全表增量同步_实现指定整库同步_或指定数据表同步配置_04---大数据之Nifi工作笔记0056
    查看>>
    NIFI1.23.2_最新版_性能优化通用_技巧积累_使用NIFI表达式过滤表_随时更新---大数据之Nifi工作笔记0063
    查看>>
    NIFI从MySql中增量同步数据_通过Mysql的binlog功能_实时同步mysql数据_根据binlog实现update数据实时同步_实际操作05---大数据之Nifi工作笔记0044
    查看>>