对象是否存活？

1、对象已死吗

       在堆里面存放着Java 世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存话”着哪些已经“死去”(即不可能再被任何途径使用的对象)。

1.1 引用计数算法

       很多教科书判断对象是否存活的算法是这样的:给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1:当引用失效时，计数器值就减1:任何时刻计数器为0的对象就是不可能再被使用的。作者面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案。
       客观地说，引用计数算法(Reference Counting) 的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著 名的应用案例，例如微软公司的COM(Component Object Model)技术、使用ActionScript 3的FlashPlayer、Python 语言和在游戏脚本领域被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但是，至少主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。
       举个简单的例子，请看代码清单3-1中的tstGCO方法:对象objA和objB都有字段instance,赋值令objA nstane二objB及ojB.instanc.-obj除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用者对方，导致它们的引用计数都不为0,于是引用计数算法无法通知GC收集器回收它们。

代码：

package com.iflytek.demo.t1;

public class Main {

    public Object instance = null;
    private static final int int_1MB = 1024*1024;

    /**
     * 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
     * @param args
     */
    private byte[] bigSize = new byte[2 * int_1MB];

    public static void main(String[] args) {
        Main m1 = new Main();
        Main m2 = new Main();

        m1.instance = m2;
        m2.instance = m1;

        m1 = null;
        m2 = null;

        //假设在此发生GC，m1和m2能否被回收
        System.gc();
    }
}

运行结果：

[GC (System.gc()) [PSYoungGen: 5935K->712K(9216K)] 5935K->720K(19456K), 0.0009994 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 712K->0K(9216K)] [ParOldGen: 8K->592K(10240K)] 720K->592K(19456K), [Metaspace: 3106K->3106K(1056768K)], 0.0031405 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 9216K, used 166K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 2% used [0x00000000ff600000,0x00000000ff6299e0,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 592K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 5% used [0x00000000fec00000,0x00000000fec94380,0x00000000ff600000)
 Metaspace       used 3132K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 343K, capacity 388K, committed 512K, reserved 1048576K

       从运行结果中可以清楚看到，GC日志中包含*5935K->712K"意味着虚拟机并没有因为这两个对象五相引用就不同收它们这也从则面说明虚报机并不是通过引用计数算法来判断对象是否存活的。

1.2 可达性分析算法

       在主流的商用程序语育(Java、 C#,甚至包括前面提到的古老的Lisp)的主流实现中，都是称通过可达性分析(Reachability Analysis)来判定对象是否存活的。这个算法的基本思路就是通过系列的称为“GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain),当个对象到GC Roots没有任何引用链相连(用图论的话来说，就是从GC Roots到这个对象不可达)时，则证明此对象是不可用的。如图3-1所示，对象objecet 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

在Java语言中，可作为GC Roots的对象包括下面几种:

• 虚拟机栈(栈帧中的本地变量表)中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常最引用的对象。
• 本地方法栈中JNI（即一般说的Natve 方法）引用的对象。

1.3 生存还是死亡

       即使在可达性分析算法中不可达的对象，也井非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宜告一 个对象死亡，至少要经历两次标记过程:如果对象在进行可达性分析后发现没有与GC-Roots相连接的引用链，那它将会被第次标记并且进行次筛选，筛选的条件是此对象是否有必要执行finalize0)方法。当对象没有覆盖finalize()方法，或者fnaliz()方法已经被虚报机调用过，虚拟机将这两种情况都视为“没有必要执行”。
       如果这个对象被判定为有必要执行fnalize0方法，那么这个对象将会放置在- 个叫做F-Queue的队列之中，并在精后由个由虚拟机自动建立的、 低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在falizl)方法中执行缓慢，或者发生了死循环(更极端的情况)，将很可能会导致F-Qucue队列中其他对象水久处于等待，甚至导致整个内存回收系统崩溃。fnizi0 方法是对象逃脱死亡命运的最后次机会，稍后GC将对F-Qucue中的对象进行第二次小规模的标记，如果对象要在falie0中成功拯救自己-一只要重新 与引用链上的任何一个对象建立关联即可，譬如把自己(this 关键字)赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合:如果对象这时候还没有选服那基本上它或真的被回收了。从代码清单3.2中我们可以看到一个对象的falizo被执行，但是它仍然可以存活。

代码：

package com.iflytek.demo.t1;

public class Main {

    public static Main SAVE_HOOK = null;

    public void isAlive(){
        System.out.println("我靠，我活下来了！");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("开始拯救对象啊");
        Main.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new Main();
        //对象第一次拯救
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以需要暂停0.5秒等待他
        Thread.sleep(500);
        if (SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("我靠，我咋死了");
        }

        //下面这段代码与上面完全相同，却拯救失败了
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以需要暂停0.5秒等待他
        Thread.sleep(500);
        if (SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("我靠，我咋死了");
        }
    }
}

运行结果：

开始拯救对象啊
我靠，我活下来了！
我靠，我咋死了

       从代码清单的运行结果可以看出，SAVE HOOK对象的finalize()方法确实被GC收集器触发过，并且在被收集前成功逃脱了。
       另外一个值得注意的地方是，代码中有两段完全一样的代码片段， 执行结果却是一次逃脱成功，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次， 如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败。
       需要特别说明的是，上面关于对象死亡时fnalize()方法的描述可能带有悲情的艺术色彩，笔者并不鼓励大家使用这种方法来拯救对象。相反，笔者建议天家尽量避免使用它，因为它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协。它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。有些教材中描述它适合做“关闭外部资源”之类的工作，这完全是对这个方法用途的种自我安慰。finalize0能做的所有工作，使用try fnally或者其他方式都可以做得更好、更及时，所以笔者建议大家完全可以忘掉Java语言中有这个方法的存在。