JVM 一个对象是否已经死亡?

前言

引用计数法

可达性分析法

引用

finalize()

方法区回收

前言

虚拟机中垃圾回收器是掌握对象生死的判官, 只要是垃圾回收器认为需要被回收的, 那么这个对象基本可以宣告"死亡". 但是也不是所有的对象, 都需要被回收, 因此, 我们在学习垃圾回收的时候, 应该多思考思考下面几个问题:

哪些对象需要回收
什么时候回收
怎么回收

JVM的自动回收对使用者来说是透明的, 但是自动也并不代表是万能的, 在某些特定的场景, 垃圾回收甚至可以成为系统的瓶颈. 垃圾回收的不确定性是我们需要去了解的, 以便写出更好的程序.

其实我们都知道只要一个对象赋值给一个引用变量, 就不会被垃圾回收器回收, 例如:

Object obj = new Object();

obj这个引用变量持有了这个对象的引用. 因此不会被回收, 但是事实却没有那么简单. 比如, 加入一个对象A持有了另外一个对象B的引用, 那么B就不会被回收吗? 并不会, 虽然对象B被A引用了, 但是对象A没有被任何对象引用, 也就是说A是会被回收的对象, 那么A中对B的引用也将会失效, 因此B也应该被回收.

因此垃圾回收的机制不会辣么随意, 如果这么随意的话, 也不会到现在还在流行.. ..

引用计数法

引用计数法是一个非常简单的判断对象是否被引用的案例, 原理很简单, 就是如果一个对象被引用, 那么其计数器就+1, 若计数器的值为0就说明没有地方引用他, 因此此时可以被回收.

但是这种方法有一种致命的问题, 那么就解决不了复杂场景的循环引用的问题. 例如对象A中的变量引用了对象B, 对象B中的变量引用了对象A, 那么他们互相持有相互的引用, 因此A和B的引用计数器都为1, 但是考虑另外一种情况, 也就是A和B以及脱离系统了, 以及用不上了, A和B可以一起被回收

举一个不恰当的例子, 例如你有一个游戏机套装, 里面有手柄和主机, 主机没了手柄不能游玩, 手柄离开了主机, 也没有任何意义, 他两相互依赖, 但是这并不会阻止你在某一天将其卖给第三方或者扔进垃圾桶.

但是这种计数法也不是一无是处. 它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。也有一些比较著名的应用案例，例如微软COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言以及在游戏脚本领域得到许多应用的Squirrel中
都使用了引用计数算法进行内存管理.

但是就Java这种会拥有复杂的引用关系的来说, 基本是舍弃了这种方法.

可达性分析法

这种算法的基本思路就是通过一系列引用结点开始向下搜索, 如果一个对象存在于这个依赖链中, 那么它就不应该被回收, 如下:

图中Object5以及其子引用obj6和obj7都不可达到其GC Roots, 也就意味着系统中没有使用到他们的地方了, 因此此时他们可以一起打包回收了 .

我们仔细回想一下, 哪些可以对象可以作为GC Roots,

虚拟机栈中的局部变量表中的局部变量, 参数等:

在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量
在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用
本地方法栈中引用的java对象
Java虚拟机内部的引用
所有被同步锁（synchronized关键字）持有的对象

引用

如果一个对象只能被标记为可回收和不可回收, 那么就过于绝对了, 因为肯定还存在一些, 可以被回收, 也可以不被回收的对象, 最简单的一个例子就是缓存, 内存不够的时候, 可以清除缓存给主程序让路, 内存够的时候, 缓存可以为系统提速.

因此JDK1.2后续版本新增对引用概念的扩充. 如下:

强引用, 如Object tem = new Object(); 只要强引用关系还存在, 就会被回收
软引用, 弱于强引用, 用来描述, 还有用, 但是非必要对象, 只要被软引用管理关联的对象, 在系统发生溢出前, 这些对象就是下一次被回收的对象. 如果这部分引用的对象被回收了还是溢出, 那么就会OOM, 在JDK 1.2版之后提供了SoftReference类来实现软引用
弱引用, 描述那么非必须的对象, 下一次GC, 无论内存是否足够, 都会被回收. 在JDK 1.2版之后提供了WeakReference类来实现弱引用
虚引用: 最弱的引用关系一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2版之后提供了PhantomReference类来实现虚引用。

finalize()

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的. 真正宣告一个对象死亡, 需要经历两次标记过程. 如果对象在进行可行性分析后发现没有与GC Roots 相连接的引用链, 那么就会被第一次标记, 随后进行一次筛选, 筛选的条件就是此对象是否有必要执行finalize方法, 假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为没必要执行finalize方法. (相当于直接被确认回收的对象)

因为finalize方法只会被调用一次, 因此已经被调用过的, 还有没有重写finalize, 都不会去执行finalize这个方法了, 被第一次标记的对象, 并且覆盖了finalize, 并且还没有被执行过的, 就会被定义为确有必要执行finalize()方法. 该对象就会被放入一个叫做FQueue的队列中, 并在稍后由一个java虚拟机创建的线程去执行这个队列里面的对象的finalize方法. 但是这个线程的调度级别很低.

这个线程被称为: Finalizer线程, 它执行finalize的方法的时候, 并不保证能完整执行完结束, 因为考虑finalize方法本身运行缓慢或者出现死循环, 就会导致FQueue里面的对象的finalize方法难以得到有效执行. 甚至导致整个内存回收子系统的崩溃.

在这个finalize里面, 这个对象将有机会脱离死亡, 收集器将对FQueue中的对象进行第二次小规模的标记只要重新与引用链上的任何一个对象建立关联即可. 例如将this关联给其他变量, 如果这个阶段还没有被引用, 那么就会被回收.

考虑如下代码, SAVE_HOOK 在一开始赋值了一个FinalizeEscapeGC对象, 然后又舍弃了这个对象, 随后调用GC, 然后在GC执行的时候, 就会像上述那样去看finalize()是否被覆盖和被调用过一次, 这里显然没有被调用, 因此就会由Finalizer线程去执行finalize方法, 这个方法里面将自己的引用再次赋值给SAVE_HOOK, 保证了这个对象重新被引用, 因此第一次回收还存活.

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;
    public void isAlive() {
        System.out.println("yes, i am still alive :)");
    }
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }
    public static void main(String[] args) throws Throwable {
        SAVE_HOOK = new FinalizeEscapeGC();
//对象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
// 因为Finalizer方法优先级很低，暂停0.5秒，以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead :(");
        }
// 下面这段代码与上面的完全相同，但是这次自救却失败了
        SAVE_HOOK = null;
        System.gc();
// 因为Finalizer方法优先级很低，暂停0.5秒，以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead :(");
        }
    }
}

第二次就没那么幸运了, 因为finalize已经被调用了, 因此第一次被标记的时候, 筛选它有没有finalize或者是否已经被执行的时候, 就已经确认了他要被回收了.

这里其实并不推荐使用这种方法(finalize), 很多地方说是回收资源, 像try-catch那样, 我觉得很牵强, 因为其不确定性, 官方也说了不推荐.

方法区回收

我们之前已经学习过了, 方法区用来存放常量池, 类名, 各种类的信息等数据, 这些东西都是在编译的时候确定好的(即使是一些动态类的扩展类, 也基本可以在运行时确认), 相比于堆区, 方法区回收的收益非常低, 堆区中由于经常新建和销毁对象, 因此收益比较高, 尤其是在新生代中，对常规应用进行一次垃圾收集通常可以回收70%至99%的内存空间 .

方法区主要手机的内容是废弃的常量和不再使用的类型. 回收废弃常量与回收Java堆中的对象非常类似, 例如一个字符串str 在常量池中, 但是没有任何一个系统的变量值为str的值, 也就是说已经没有了任何字符串对象引用常量池中的str字符串常量, 虚拟机中也米有其他地方需要引用这个字面量, 此时发生回收, 这个字面量字符串就会被回收, 常量池中其他的类, 接口, 方法的定义也是如此,

常量好判断, 那么不再被使用的类呢? 一个类被使用就得看它是不是有实例对象, 但是没有实例对象的类, 也不一定就不会被再次使用. 但是一般的需要遵循下面这是三个步骤: