网站建设资讯

NEWS

网站建设资讯

java代码可达性分析,可达性模型分析

可达性分析算法及4种引用说明

哪些对象可以被回收 彻底失去引用的对象  GC roots 可达性分析算法 可以判断 没有引用链的就可以被回收。这算第一次标记。第二次标记成功后会被回收。

马龙ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为成都创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18982081108(备注:SSL证书合作)期待与您的合作!

对象在内存中的状态:

可达状态:

可恢复状态:

不可达状态:

             

判断对象是否存活都与引用有关,下面介绍一下引用的分类:

引用分类:

强引用;Object obj = new Object()

软引用;notmust

弱引用;

虚引用;

数组、对象

类似:Object obj = new Object()

只要存在强引用,垃圾收集器永远不会回收掉被引用的对象

描述一些还有用但并非必须的对象。在系统将要发生内存溢出异常之前,将会把这些对象列入回收范围之中进行第二次回收。如果这次回收之后还没有足够的内存——抛出内存异常

内存充足,不会回收

内存不足,回收

非必需对象

垃圾回收机制运行时,不管内存充足与否,都会回收

不能单独存在,必须和引用队列联合使用。

无法通过虚引用来去的一个对象实例。

对象存活判定算法:

引用计数算法:

思路:

给对象添加一个引用计数器,每当一个地方引用它时,计数器加1;

当引用失效时,计数器值就减1;

任何时刻计数器为0的对象就是不能再被使用的。

缺点:

很难解决对象之间相互循环引用的问题。导致他们的引用计数都不为0,于是引用计数算法无法通知GC收集器回收他们。

思路:

通过一系列的成为“GC Roots”的对象作为起始点,

从这些节点开始向下搜索,搜索所走过的路径成为引用链(Reference Chain),

当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。

应用:

现在主流的商用程序语言(java,C#)都是通过可达性分析来判断对象是否存活的。

Java中,可作为GC Roots的对象包括:

虚拟机栈(栈帧中的本地变量表)中引用的对象;

方法区中类静态属性引用的对象;

方法区中常量引用的对象;

本地方法栈中JNI(即Native方法)引用的对象;

对象死亡(被回收)前的最后一次挣扎

  即使在可达性分析算法中不可达的对象,也并非是“非死不可”,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程。

  第一次标记:如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链,那它将会被第一次标记;

  第二次标记:第一次标记后接着会进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。在finalize()方法中没有重新与引用链建立关联关系的,将被进行第二次标记。

  第二次标记成功的对象将真的会被回收,如果对象在finalize()方法中重新与引用链建立了关联关系,那么将会逃离本次回收,继续存活。

收集器 

浅谈CMS垃圾收集器与G1收集器

Java之美[从菜鸟到高手演变]之JVM内存管理及垃圾回收

jdk8:垃圾回收算法

怎么验证java的gc是否会回收了某个不用的对象了。我有段代码有性能问题,需要调优,想知道怎么看

1. 引用计数器算法

解释

系统给每个对象添加一个引用计数器,每当有一个地方引用这个对象的时候,计数器就加1,当引用失效的时候,计数器就减1,在任何一个时刻计数器为0的对象就是不可能被使用的对象,因为没有任何地方持有这个引用,这时这个对象就被视为内存垃圾,等待被虚拟机回收

优点

客观的说,引用计数器算法,他的实现很简单,判定的效率很高,在大部分情况下这都是相当不错的算法

其实,很多案例中都使用了这种算法,比如 IOS 的Object-C , 微软的COM技术(用于给window开发驱动,.net里面的技术几乎都是建立在COM上的),Python语言等.

缺陷

无法解决循环引用的问题.

这就好像是悬崖边的人采集草药的人, 想要活下去就必须要有一根绳子绑在悬崖上. 如果有两个人, 甲的手拉着悬崖, 乙的手拉着甲, 那么这两个人都能活, 但是, 如果甲的手拉着乙, 乙的手也拉着甲, 虽然这两个人都认为自己被别人拉着, 但是一样会掉下悬崖.

比如说 A对象的一个属性引用B,B对象的一个属性同时引用A A.b = B() B.a = A(); 这个A,B对象的计数器都是1,可是,如果没有其他任何地方引用A,B对象的时候,A,B对象其实在系统中是无法发挥任何作用的,既然无法发挥作用,那就应该被视作内存垃圾予以清理掉,可是因为此时A,B的计数器的值都是1,虚拟机就无法回收A,B对象,这样就会造成内存浪费,这在计算机系统中是不可容忍的.

解决办法

在语言层面处理, 例如Object-C 就使用强弱引用类型来解决问题.强引用计数器加1 ,弱引用不增加

Java中也有强弱引用

2. 可达性分析算法

解释

这种算法通过一系列成为 "GC Roots " 的对象作为起始点,从这些节点开始向下搜索所有走过的路径成为引用链(Reference Chain) , 当一个对象GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达),则证明此对象是不可用的

优点

这个算法可以轻松的解决循环引用的问题

大部分的主流java虚拟机使用的都是这种算法

3. Java语言中的GC Roots

在虚拟机栈(其实是栈帧中的本地变量表)中引用的对象

在方法区中的类静态属性引用对象

在方法区中的常量引用的对象

在本地方法栈中JNI(即一般说的Native方法)的引用对象

可达性分析起始点未定位原因

相对于引用计数算法而言,可达性分析算法不仅同样具备实现简单和执行高效等特点,更重要的是该算法可以有效解决引用计数算法中循环引用的问题,防止内存泄漏的发生

java选择的就是可达性分析算法,这种类型的垃圾收集通常也叫做追踪性垃圾收集

所谓GC ROOTS 根集合就是一组必须活跃的引用

基本思路:

1.可达性分析算法是以根对象集合(GC Roots)为起始点,按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达

2.使用可达性分析算法后,内存中的存活对象都会被根对象集合直接或间接连接着,搜索所走过的路径称为引用链

3.如果目标对象没有任何引用链项链,则是不可达的,就意味着该对象已经死亡,可以标记为垃圾对象

4.在可达性分析算法中,只有能够被根对象集合直接或者间接连接的对象才是存活对象

JVM并发的可达性分析

j当面试扯到jvm这一部分的时候,面试官大概率会问你 jvm怎么判断哪些对象应该回收呢 ?

你会脱口而出 引用计数算法 和 可达性分析算法 。

引用计数法: 在对象中添加一个引用计数器,每当一个地方引用它时,计数器就加一;当引用失效时,计数器值就减一;任何时刻计数器为零的对象就是不可能再被使用的。

但是这样的算法有一个问题?

就是不能解决循环依赖的问题。

可达性分析算法的思路 就是通过一系列的“GC Roots”,也就是根对象作为起始节点,从根节点开始,根据引用关系向下搜索,搜索过程所走过的路径称为引用链,如果某个对象到GC Roots间没有任何引用链相连。就是说从GC Roots到这个对象不可达时,则证明此对象是不可能再被使用的,是可以被回收的对象。

接下来面试官可能会问:

你刚刚谈到了根节点,那你知道哪些对象可以作为根对象吗?

你刚刚谈到了引用,那你知道java里面有哪几种引用吗?

你刚刚谈到了可达性分析算法,那如果在该算法中被判定不可达对象,是不是一定会被回收呢?

(这这些问题,文末会给出解答)

这些问题太常规了,本文要讲一些不那么常见的: 并发标记 , 浮动垃圾 。

CMS和G1都有一个并发标记的过程,并发标记要解决什么问题?带来了什么问题?怎么解决这些问题呢?

刚刚我们谈到的可达性分析算法是需要一个理论上的前提的: 该算法的全过程都需要基于一个能保障一致性的快照才能够分析,这意味着必须全程冻结用户线程的运行。 而为了不冻结用户线程的运行,那我们就需要让垃圾回收线程和用户线程同时运行。

那我们先假设不并发标记,即只有垃圾回收线程在运行的流程是怎样的:

第一步:找到根节点,也就是我们常说的 根节点枚举 。

在这个过程中,由于GC Roots是远远小与整个java堆中的全部对象,而且在OopMap此类优化技巧的加持下,它带来的停顿是非常短暂且固定的, 可以理解为不会随着堆里的对象的增加而增加 ,如图:

首先我们要搞清楚一个问题: 为什么遍历对象图的时候必须在一个能保证一致性的快照中?

为了说明这个问题,我们引入 “三色标记” 方法。

什么是“三色标记”?

在遍历对象图的过程中,把访问的对象按照"是否访问过"这个条件标记成以下三种颜色:

白色:表示对象未被垃圾回收器访问过 。

显然可达性分析刚开始的时候,所有的对象都是白色,若在结束的时候,仍是白色的对象,即代表不可达。

黑色:表示已经被垃圾回收器访问过,且这个对象的所有引用都已经扫描过

黑色的对象代表已经扫描过,它是安全存活的,如果有其它的对象引用指向了黑色对象,无须重新扫描一遍。黑色对象不可能直接(不经过灰色对象)指向某个白色对象。

灰色:表示已经被垃圾回收器扫描过,但这个对象至少存在一个引用还没有被扫描 。

如下图所示:

我们先看一下正常标记的过程:

首先是初始状态,很简单,只有GC Roots是黑色的。同时需要注意下面的图片的箭头方向,代表的是有向的,比如其中的一条引用链是:

跟节点-5-6-7-8-11-10

如果在标记的过程中,用户线程修改了引用关系,就会出现下面的情况:

有一个大佬叫Wilson,他在1994年在理论上证明了, 只有同时满足以下两个条件时 ,会产生“对象消失”的问题,原来应该是黑色的对象被标记成了白色。

增量更新要破坏的是第一个条件(赋值器插入了一条或者多条从黑色对象到白色对象的新引用),当黑色对象插入新的指向白色对象的引用关系时,就将这个新插入的引用 记录下来 ,等并发扫描结束之后,再以这些记录过的引用关系中的黑色对象为根, 重新扫描一次 。

可以简化的理解为: 黑色对象一旦插入了指向白色对象的引用之后,它就变回了灰色对象 。

下面的图就是一次并发扫描结束之后,记录了黑色对象5新指向了白色对象9:

原始快照要破坏的是第二个条件(赋值器删除了全部从灰色对象到该白色对象的直接或间接引用),当灰色对象要删除指向白色对象的引用关系时,就将这个要删除的引用记录下来,在并发扫描结束之后,再以这些记录过的引用关系中的灰色对象为根,重新扫描一次。

可以简化理解为:无论引用关系删除与否,都会按照刚刚开始扫描那一刻的对象图快照开进行搜索。

接下来回答一下,上面遗留的几个问题:

GC管理的主要区域是Java堆,一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC Roots,被GC Roots引用的对象不被GC回收。

Class - 由系统类加载器(system class loader)加载的对象,这些类是不能够被回收的,他们可以以静态字段的方式保存持有其它对象。

Thread - 活着的线程

Stack Local - Java方法的local变量或者参数

JNI Local、JNI Global

Monitor Used - 用于同步的监控对象

在Java语言里,可以作为GC Roots对象的包括如下几种:

你知道java里面有哪几种引用吗?

在可达性分析算法判定为不可达的对象,是不是一定会被回收呢?

即使在可达性算法中不可达的对象也不一定是非死不可的,这时候它们暂时处于“缓刑”阶段,要真正宣告它的死亡还需要经历两次的标记阶段。

第一次标记

在对象可达性算法不可达时,进行第一次标记,并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法或者该方法被虚拟机调用过,虚拟机将这两种情况视为“没有必要去执行”,回收。

如果该对象被判定为有必要执行finalize()方法,那么这个对象会被放置到一个叫做F-Queue的队列中,并在稍后由一个虚拟机自动建立的、低优先级的Finalize线程去执行它。这里所谓的执行就是去触发该方法,但是并不会承诺等待它执行结束,这样做的原因是,如果对象在finalize()方法中执行缓慢,或者发生死循环,将会导致整个队列中的对象处于等待之中。

第二次标记

finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中拯救自己——只要重新与引用链上的一个对象重新建立关联即可,比如将自己(this关键字)赋值给某个类变量或者成员变量,那么在第二次标记的时候就会被移除“即将回收”的集合;如果对象这时候还没有逃脱,那么就会被真的回收了。

注意:第二次自救失败是因为任何一个对象的finalize()方法只能执行一次,如果第二次回收,就不会执行finalize方法了!

(未完待续)

Java可达性分析算法会不会出现循环引用问题

GC Root在对象图之外,是特别定义的“起点”,不可能被对象图内的对象所引用。

一个常见的误解是以为GC Root是一组对象。

实际情况是GC Root通常是一组特别管理的指针,这些指针是tracing GC的trace的起点。它们不是对象图里的对象,对象也不可能引用到这些“外部”的指针,所以题主想像的情况无法成立。

另外,tracing GC能正确处理循环引用,保证每个活对象只会被访问一次就能确定其存活性。对象图里是否存在循环引用,tracing GC都能正确判断对象的存活与否。


当前文章:java代码可达性分析,可达性模型分析
新闻来源:http://cdweb.net/article/hedcgg.html