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

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

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

对象在内存中的状态：

可达状态：

可恢复状态：

不可达状态：

                    

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

引用分类：

强引用；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:垃圾回收算法

相关问答

Q1: 怎么验证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方法)的引用对象

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

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

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

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

基本思路:

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

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

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

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

Q3: 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方法了！

(未完待续)

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

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

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

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

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