白小姐谈JVM的垃圾回收器与内存分配策略的《可达性分析判死算法》

一、垃圾回收

 对于程序计数器，虚拟机栈，本地方法栈这三个部分区域而言，其生命周期与相关线程有关，随线程而生，随线程而灭，并且这三个区域的内存分配与回收具有确定性，因为当方法结束或者线程结束时，内存就自然跟着线程回收了。所以我们需要关注的是Java堆与方法区这两个线程共享的区域。

1.1、如何判断对象已“死”

Java堆中存放着几乎所有的对象实例，垃圾回收器在对堆进行垃圾回收之前，首先要判断这些对象哪些还存活，哪些已经“死去”，判断对象是否已“死”有以下几种算法

1.1.1、引用计数法：

引用计数法描述的算法为：
给每个对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能在被使用时，即对象已“死”。
引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个不错的算法。比如pathoy语言就采用引用计数法来进行内存管理。
但是，在主流的JVM中并没有使用应用引用技术法历来管理内存，最主要的原因就是引用计数无法解决对象的循环引用问题。
接下来我们来观察一下我们的循环引用问题：

package count;
/*
* JVM参数：-xx ：+PrintGC
*
*/
public class Test {
public Object instance=null;
private static int _1MB =1024*1024;
private byte[] bigSize=new byte[2*_1MB];

    public static void testGC() {
        Test test1=new Test();
        Test test2=new Test();
        test1.instance=test2;
        test2.instance=test1;
        test1=null;
        test2=null;
        //强制JVM进行垃圾回收
        System.gc();
    }
    public static void main(String[] args){
        testGC();
    }
}

我们现在看一下我们的运行结果：

[GC (System.gc())  7437K->896K(125952K), 0.0011457 secs]
[Full GC (System.gc())  896K->696K(125952K), 0.0056098 secs]

Process finished with exit code 0

我们从结果可以看出，GC日志库包含“7437k->896k(125952k)”,意为着虚拟机并没有因为这两个对象相互引用就不回收他们。即JVM并不使用引用计数法来判断对象是否活着。

1.1.2可达性分析算法

Java并不采用引用计数法来判断对象是否已死，而采用可达性分析来判断对象是否存活
此算法的核心思想为：通过一系列称为GC Roots的对象作为起始点，这些节点开始向下搜索，搜索走过的路径称之为**“引用链”，**当一个对象到“GCRoots”没有任何的引用链相连时（从GCRoots到这个对象不可达时，证明这个对象是不可用的）。
此算法的核心思想为：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为“引用链”，当一个对象到GC Roots
没有任何的引用链相连时，证明此对象是不可用的。以下图为例：

对象Object5-Object7之间虽然彼此还有关联，但是它们到GC Roots是不可达的，因此他们会被判定为可回收对象。

在Java语言中可作为GCRoots的对象包含下面几种

1、虚拟机栈（栈帧中的本地变量表）中的引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中（Native方法）引用的对象

在JDK1.2以前，Java中引用的定义很传统，如果引用类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用，这种定义很狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态
我们希望能够描述这样一类对象：当内存空间还足够时，则能保存在内存中；如果内存空间在进行垃圾回收后还是非常紧张，则可以抛弃这些对象，很多系统中的缓存对象都符合这样的场景。
在JDK1.2之后，Java对引用的概念做了扩充，将引用分为强引用、软引用、弱引用和虚引用四种，这四种引用的强度依次递减
 强引用:强引用指的是在程序代码之中普遍存在的，类似于Object obj=new Object()这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象实例。
 软引用：软引用是用来描述一些还有用但是不是必须的对象，对于软引用关联的对象，在系统将要发生内存溢出之前，会把这些对象列入回收范围之中进行二次回收。如果这次回收还是没有足够的内存空间，才会抛出内存溢出异常，在JDK1.2之后，提供了SoftReferce类来实现软引用。
 弱引用：弱引用也是用来描述非必需对象的，但是它的轻度要弱于软引用。被弱引用关联的对象只能生存到下一次垃圾回收发生之前，当垃圾回收器开始进行工作时，无论当前内容是否够用，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。
 虚引用：虚引用也被称为幽灵引用或者是幻影引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存构成影响，也无法通过虚引用来获取一个对象实例，为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。PhantomReference

生存还是死亡

即使在可达性分析算法中不可达的对象，也并非“非死不可”的，这时候他们暂时处在“缓刑”阶段.要宣告一个对象的正真死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GCRoots相连接的引用链，那他竟会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法。当对象没有覆盖finalize（）方法或者是finalize（）方法已经被JVM调用过，虚拟机会将这两种情况都视为“没有必要执行”，此时的对象才是真正的“死亡”的对象。
如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放在一个叫做F——Queue的队列之中，并在稍后由一个虚拟机自动建立的，低优先级的Finalizer线程去执行它（这里所说的执行指的是虚拟机会触发finalize（）方法）finalize（）方法是对象逃脱死亡的最后一次及hi，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象在finalize（）中成功拯救自己（只需重新与引用链上的任何一个对象建立起关联关系即可），那在第二次标记时他将会被移出“即将回收”的集合，如果对象这时候还是没有逃脱，那基本上他就是真的被回收了。

public class Test {
        public static Test test;
        public void isAlive(){
            System.out.println("我还活着");
        }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed");
        test=this;
    }
    public static void main(String[] args) throws Exception {
            test=new Test();
            test=null;
            System.gc();
            Thread.sleep(500);
            if(test !=null){
                test.isAlive();
            }else{
                System.out.println("我死了");
            }
        test=null;
        System.gc();
        Thread.sleep(500);
        if(test!=null){
            test.isAlive();
        }else{
            System.out.println("我死了");
        }
        }

}

运行结果是：

finalize method executed
我还活着
我死了

我们的自救机会只有一次。
我们能够看到，我们的两份代码是一样的，但是我们的结果却是一个还活着，而另一个已经出现死亡。这是因为，任何一个对象的finalize（）方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又勉良被回收，它的finalize（）方法不会被再次执行，因此第二段代码的自救行动将会失败。

自救过程：