java 实现 引用计数器_java 对象存活分析——引用计数法&可达性分析

java虚拟机总共分为五个区域，其中三个是线程私有：程序计数器，虚拟机栈，本地方法栈，两个是线程共享：堆，方法区。线程私有的区域等到线程结束时(栈帧出栈时)会自动被释放，空间比较容易清理。而线程共享的java堆和方法区中的空间较大而且没有线程的回收容易产生很多垃圾信息，GC垃圾回收真正关心的就是这部分。

java堆和方法区主要存放各种类型的对象(方法区中也存储一些静态变量和全局常量等信息)，那么我们在使用GC对其进行回收的时候首先要考虑的就是如何判断一个对象是否应该被回收。也就是要判断一个对象是否还有其他的引用或关联使得这个对象处于存活的状态。我们需要将不在存活状态的所有对象标记出，以便于GC进行回收。

判断对象是否存活有两种比较常见的方法：引用计数法与可达性分析算法。

引用计数法

引用计数法的逻辑非常简单，但是存在问题，java并不采用这种方式进行对象存活判断。

引用计数法的逻辑是：在堆中存储对象时，在对象头处维护一个counter计数器，如果一个对象增加了一个引用与之相连，则将counter++。如果一个引用关系失效则counter–。如果一个对象的counter变为0，则说明该对象已经被废弃，不处于存活状态。

这种方法来标记对象的状态会存在很多问题：

1 jdk从1.2开始增加了多种引用方式：软引用、弱引用、虚引用，且在不同引用情况下程序应进行不同的操作。如果我们只采用一个引用计数法来计数无法准确的区分这么多种引用的情况。

引用计数法无法解决多种类型引用的问题。但这并不是致命的，因为我们可以通过增加逻辑区分四种引用情况，虽然麻烦一些但还算是引用计数法的变体，真正让引用计数法彻底报废的下面的情况。

2 如果一个对象A持有对象B，而对象B也持有一个对象A，那发生了类似操作系统中死锁的循环持有，这种情况下A与B的counter恒大于1，会使得GC永远无法回收这两个对象。

可达性分析算法

在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。这个算法的基本思路就是通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，下图对象object5, object6, object7虽然有互相判断，但它们到GC Roots是不可达的，所以它们将会判定为是可回收对象。

这里写图片描述

那么那些点可以作为GC Roots呢？一般来说，如下情况的对象可以作为GC Roots：

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

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

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

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

HotSpot虚拟机如何实现可达性算法？

java中的主流虚拟机HotSpot采用可达性分析算法来确定一个对象的状态，那么HotSpot在具体实现该算法时采用了哪些结构？

使用OopMap记录并枚举根节点

HotSpot首先需要枚举所有的GC Roots根节点，虚拟机栈的空间不大，遍历一次的时间或许可以接受，但是方法区的空间很可能就有数百兆，遍历一次需要很久。更加关键的是，当我们遍历所有GC Roots根节点时，我们需要暂停所有用户线程，因为我们需要一个此时此刻的”虚拟机快照”，如果我们不暂停用户线程，那么虚拟机仍处于运行状态，我们无法确保能够正确遍历所有的根节点。所以此时的时间开销过大更是我们不能接受的。

基于这种情况，HotSpot实现了一种叫做OopMap的数据结构，这种数据结构在类加载完成时把对象内的偏移量是什么类型计算出，并且存放下位置，当需要遍历根结点时访问所有OopMap即可。

用安全点Safepoint约束根节点

如果将每个符合GC Roots条件的对象都存放进入OopMap中，那么OopMap也会变得很大，而且其中很多对象很可能会发生一些变化，这些变化使得维护这个映射表很困难。实际上，HotSpot并没有为每一个对象都创建OopMap，只在特定的位置上创建了这些信息，这些位置称为安全点(Safepoints)。

为了保证虚拟机中安全点的个数不算太多也不是太少，主要决定安全点是否被建立的因素是时间。当进行了耗时的操作时，比如方法调用、循环跳转等时会产生安全点。此外，HotSpot虚拟机在安全点的基础上还增加了安全区域的概念，安全区域是安全点的扩展。在一段安全区域中能够实现安全点不能达成的效果。