JVM学习笔记三：对象死亡算法与过程概述

一、前言

在Java内存运行时区域中，程序计数器、虚拟机栈和本地方法栈这三个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基 本上是在类结构确定下来时就已知的。因此这几个区域的内存分配和回收都具备确定性，当方法结束或者线程结束时，内存就自然跟随着回收了。

而Java堆和方法区这两个区域，只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。因此垃圾收集器所关注的正是这部分的内存改如何管理。

要想收集垃圾，首先先确定判定对象是否死亡，以下为判断对象死亡的算法。

 

 

二、引用计数算法

 

1.概念

对于创建的每一个对象都有一个与之关联的计数器，当有地方引用对象时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能在被使用的，即若计数器为零，就会释放该对象占用的内存空间，同时将该对象引用的其他对象的计数器进行减一操作。

 

2.优点

• 实现简单，效率高。内存回收可以穿插在程序的运行中，当某一对象的引用计数器为零时，可以立即对该对象所占用的内存空间进行回收。
• 对象回收不需要另外GC线程，业务线程就能解决，这样能避免FULL GC引起的程序暂停。

 

3.缺点

• 无法解决循环引用。一个父对象持有一个子对象的引用，子对象也持有父对象的引用的话，这时父子对象的引用计数都是1，都不能被回收。

 

 

三、可达性分析算法

 1.概念

通过一系列“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”，如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

 

上图中的对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的， 因此它们将会被判定为可回收的对象。

可作为GC Roots的对象包括以下几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象，如：各个线程被调用的方法堆栈中使用到的 参数、局部变量、临时变量等；
• 在方法区中类静态属性引用的对象，如：Java类的引用类型静态变量；
• 在方法区中常量引用的对象，如：字符串常量池里的引用；
• 在本地方法栈中native方法引用的对象；
• Java虚拟机内部的引用，如：基本数据类型对应的Class对象，一些常驻的异常对象（比如 NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器；
• 所有被同步锁（synchronized关键字）持有的对象；
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

 

2.优点

可达性分析算法可以解决引用计数算法不能解决的循环引用问题。只根据GC Roots出发到的对象进行判断，无法到达便不会将它们键入存活对象合集中。

 

3.缺点

在多线程环境下，其他线程可能会更新已经访问过的对象中的引用，从而造成误报（将引用设置为null）或者漏报（将引用设置为未被访问过的对象）。

误报会导致Java虚拟机损失了部分垃圾回收的机会。漏报则比较麻烦，因为垃圾回收器可能回收事实上仍被引用的对象内存。 一旦从原引用访问已经被回收了的对象，则很有可能会直接导致Java虚拟机崩溃。

 

 

四、引用

在JDK1.2版之前，Java里面的引用定义为：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称该reference数据是代表某块内存、某个对象的引用。

在JDK1.2版之后，Java对引用的概念进行了扩充，将引用分为强引用（Strongly Re-ference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

• 强引用是最传统的“引用”定义，是指在程序代码中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。强引用可以直接访问目标对象。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。也正因如此，强引用可能会导致内存泄漏问题。
• 软引用是用来描述一些有用但非必须的对象，只被软引用关联着的对象，在系统将要发生内存溢出异常钱，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出OOM。软引用主要实现类似缓存的功能，在内存足够的情况下直接通过软引用取值，无需从繁忙的真实来源查询数据，提升速度；当内存不足时，自动删除这部分缓存数据，从真正的来源查询这些数据。使用软引用能防止内存泄露，增强程序的健壮性。在JDK 1.2版之后提供了SoftReference类来实现软引用。
• 弱引用也是用来描述那些非必须对象，但是它的强度比弱引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。弱引用主要用于监控对象是否已经被垃圾回收器标记为即将回收的垃圾，可以通过弱引用的isEnQueued方法返回对象是否被垃圾回收器标记。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2版之后提供了WeakReference类来实现弱引用。
• 虚引用也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2版之后提供了PhantomReference类来实现虚引用。

 

 

五、对象回收过程（finalize()方法详解）

对象的死亡至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法[注1]，假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为确有必要执行finalize()方法，那么该对象会将被放置在一个名为F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。这里所说的“执行”是指虚拟机会触发这个方法开始运行，但并不承诺一定会等待它运行结束。 这样做的原因是，如果某个对象的finalize()方法执行缓慢，或者更极端地发生了死循环，将很可能导致F-Queue队列中的其他对象永久处于等待，甚至导致整个内存回收子系统的崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己 （this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

/** 
 *   此代码演示两点：
 *   1.对象可以在被GC时自我拯救
 *   2.finalize()方法最多只会被系统自动调用一次
 *   
 */
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 method executed!
yes, i am still alive :)
no, i am dead :(

 

实际项目中，因为finalize()方法并像C或者C++语言中的析构函数，它是Java刚诞生时为了使传统C、C++程序员更容易接受Java所做出的一 项妥协，所以本身存在以下缺点：

• Java语言规范并不保证finalize方法会被及时地执行、而且根本不会保证它们会被执行。
• 就算finalize()函数被调用, 它被调用的时间充满了不确定性, 因为程序中其他线程的优先级远远高于执行finalize（）函数线程的优先级。也许等到finalize()被调用, 数据库的连接池或者文件句柄早就耗尽了。
• 重写finalize()方法会导致回收对象的时间延长。finalize()和垃圾回收器的运行本身就要耗费资源, 也许会导致程序的暂时停止。
• 如果一种未被捕获的异常在使用finalize方法时被抛出，这个异常不会被捕获，finalize方法的终结过程也会终止，造成对象出于破坏的状态。被破坏的对象又很可能导致部分资源无法被回收, 造成浪费。

综上所述，应当避免使用finalize()方法！

 

 

六、回收方法区

尽管在《Java虚拟机规范》中提过可以不要求虚拟机在方法区中实现垃圾收集，并且方法区的回收的判定条件苛刻，回收效率不高，但当其无法满足内存分配需求时，也会抛出OutOfMemoryError异常，所以这块内存区域同样需要垃圾回收。

方法区的垃圾收集主要回收两部分内容：

1. 废弃的常量；
2. 不再使用的类型；

判断常量是否为废弃的情况类似于Java堆中的对象回收，即没有任何字符串对象引用目标常量，且虚拟机中也没有其他地方引用这个字面量，这是若发生内存回收，并且垃圾收集器判定确有必要的话，该常量就会被判定为废弃常量进行回收。

判定不再被使用的类条件相对苛刻，需要同时满足三个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收（这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的）
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

当满足以上三个条件后也不是必然被回收，可以通过HotSpot虚拟机提供的参数进行控制，决定是否回收。在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

 

 

注：

1. Java Object.Finalize，finalize()是Object的protected方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。一般用于释放非Java 资源（如打开的文件资源、数据库连接等）,或是调用非Java方法（native方法）时分配的内存（比如C语言的malloc()系列函数）。任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临 下一次回收，它的finalize()方法不会被再次执行。

 

 

 

参考资料

《深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）》