深入理解Java虚拟机（二）如何判断对象已“死”、回收方法区

  我们通过学习可以知道Java运行内存区域划分为五个部分，其中程序计数器、Java虚拟机栈、本地方法栈这三个是线程私有的，其生命周期与相关的线程相关，随着线程而生，随着线程而灭。 并且这三个区域的内训分配与回收具有确定性，因为当方法结束或者线程结束时，内存就自然跟着线程回收了。那么我们会想到剩下的两个区：Java堆、方法区，它们是线程共享的，伴随着对象的“生”和“死”，那么它在这两个地方的内存是如何分配和回收的呢？这就是我写这篇博客的意义：总结Java堆和方法区内存的分配和回收。

1. 如何判断对象已死？

  对于内存分配与回收就像是我们去一家非常火爆的餐厅吃饭，如果我们去的早的话，就会有空的位置，店员就会带着我们去空的位置坐下，我们就会开始点餐吃饭，我吃完离开的话，店员就要去收拾桌子，以便让其他顾客进行用餐。那么他要去收拾桌子，他就需要判断我是离开还是去洗手间，那么是不是就需要判断我是否用餐结束？
  类比于内存的分配和回收就是，现在要实例对象（我去餐厅吃饭）了，需要分配内存空间（店员给我找地方），有空的内存空间（坐下点餐），执行完毕后（用餐结束），垃圾回收器需要进行垃圾回收（店员收拾桌子），要回收之前就要判断该对象已经方法已经执行结束（用餐结束）？这要就提出了我们的核心：Java堆中存放着几乎所有的对象的实例，垃圾回收器在对堆进行垃圾回收前，首先要判断这些对象是否存活，哪些对象已经“死去”。下面就介绍几种判断对象是否已“死”的算法。

1.1 引用计数法

算法描述：

给对象增加一个引用计数器，每当有一个地方易用它是，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就不能在被使用，即对象已“死”。

举例：

  引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个不错的算法。例如python语言就采用了引用计数法进行内存管理。但是在主流的JVM中没有选用引用计数法来管理内存，最主要的原因是引用计数法无法解决对象的循环引用问题。
观察下面的例子：

public class TestGC {
    private Object instance;
    private byte[]  bigSize = new byte[2 * 1024 * 1024];

    public static void main(String[] args) {
        TestGC testGC1 = new TestGC();
        TestGC testGC2 = new TestGC();
        // 相互引用
        testGC1.instance = testGC2;
        testGC2.instance = testGC1;
        // 对象设置为null：告诉虚拟机，两个对象不使用了
        testGC1 = null;
        testGC2 = null;
        // 手动GC
        System.gc();
		// 注意：提醒java虚拟机的垃圾回收器运行回收内存的垃圾，
		//			但Java语言规范并不保证GC一定会执行。
    }
}

运行结果： 从运行结果可以看出GC日志包含“6100K->776K(125952K)”，意味着虚拟机并没有因为这两个对象互相引用结束就不回收他们，即JVM并不使用计数法来判断对象是否存活。
画图：

1.2 可达性分析算法

  在上面我们学习了引用计数法，也知道了Java并不采用引用计数法来判断对象是否已“死”。
核心思想： 通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为“引用链”，当一个对象到GC Roots没有任何引用链相连时（从GC Roots到这个对象不可达）时，证明此对象是不可用（已“死”）的。
举例分析：

Java采用的时“可达性分析”来判断对象是否存活。
在Java语言中，可作为GC Roots的对象包含下面几种：

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

1.3 认识引用

  在上面我们不停的说对象引用，那么引用是什么？在这里我们解释一下。
JDK1.2之前：
  在JDK1.2以前，Java中引用的定义很传统：如果引用类型的数据中存储的数值代表的时另一块内存的其实地址，就称这块内存代表着一个引用。这种定义有些狭隘，一个对象在这种定义下只有被引用或者没有引用两种状态。
  我们希望能描述一类对象（类似于餐厅订餐）：当内存空间还足够时，则能保存在内存中；如果内存空间在进行垃圾回收后还是非常紧张，则可以抛弃这些对象。很多系统中的缓存对象都符合这样的场景。
JDK1.2之后：
  在JDK1.2之后，Java对于引用的概念做了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference） 和虚引用（Phantom Reference） 四种，这四种引用的强度依次递减。

1. 强引用： 在程序代码之中普遍存在的，类似于Object obj = new Object()这类的引用，只要强引用还存在，垃圾回收器永远不会回收被引用的对象实例。
2. 软引用： 用来描述一些还有用但不是必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出之前，会把这些对象列入回收范围之中进行二次回收。如果这次回收还是没有足够的内存空间才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现引用。
3. 弱引用： 也用来描述非必需对象的。但是它的强度弱于软引用。被弱引用关联的对象只能生存到下一次垃圾回收发生之前（一次回收）。在JDK1.2之后提供了WeakReference类来实现弱引用。
4. 虚引用： 也被称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

1.4 生存还是死亡？

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

  上述文字的图述：

举例：对象的自我拯救

public class TestForLive {
    public static TestForLive testForLive;
    public void islive(){
        System.out.println("活着");
    }

    @Override   // 覆写finalize()方法
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("逃离死亡");
        testForLive = this;
    }

    public static void main(String[] args) {
        testForLive = new TestForLive();    // 1.有用
        testForLive = null; // 2.无用
        System.gc();    // 3.垃圾回收   ---> 回收不掉，因为覆写了finalize
        // GC需要一定的时间
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 判断对象是否已经“死亡”
        if(testForLive != null){
            testForLive.islive();
        }else{
            System.out.println("对象已经死亡");
        }
        testForLive = null;
        // 4. 再次垃圾回收
        System.gc();
        // GC需要一定的时间
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 判断对象是否已经“死亡”
        if(testForLive != null){
            testForLive.islive();
        }else{
            System.out.println("对象已经死亡");
        }
    }
}

 从上面的例子中我们可以看到，finalize()方法确实被JVM触发，并且对象在被收集前成功逃脱。
 从上面的代码我们会发现，两次调用GC进行垃圾回收，结果第一次成功逃脱，第二次逃脱失败。这是因为，任何一个对象的finalize()方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又面临一次回收，它的finalize()方法不会被再次执行，因此第二次逃脱失败。

2. 回收方法区

方法区（永久代）的垃圾回收主要是收集两部分内容：废弃常量和无用的类。
回收废弃常量和回收Java堆中的对象十分类似。以常量池中字面量（直接量）的回收为例，加入一个字符串"abc"已经进入了常量池，但是当前系统没有任何一个String对象引用常量池的"abc"常量，也没有在其他地方引用这个字面量，如果此时发生GC并且有必要的话，这个"abc"常量会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与常量类似。

2.1 如何判断一个类是无用的类？

判定一个类是否是“无用的类”则相对常量复杂很多。类需要同时满足下面三个条件才会被算是“无用的类”：

1. 该类的所有实例都已经被回收（即在Java堆中不存在任何该类的实例）
2. 加载该类的ClassLoader已经被回收《class通过ClassLoader加载》
3. 该类对应的Class对象没有任何其他地方被引用，无法在任何地方通过反射访问该类的方法。

JVM可以对同时满足上述三个条件的无用类可以进行回收，但是也仅仅只是“可以”而不是“必然”。在大量使用反射、动态代理等场景都需要JVM具备类卸载的功能来防止永久代的溢出。