JVM（4）——垃圾收集与引用类型（强、软、弱和虚引用）

这里会记录 《深入理解java虚拟机》的所有知识点哟~

概述

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

而java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收是动态的，垃圾收集器所关注的是这部分内存。

对象已死吗

在堆里面存放着几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”

1. 引用计数算法

判断一个对象是否存活的算法通常是这样的

• 给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；
• 当引用失效时，计数器值就减1；
• 任何时刻计数器为0的对象就是不可能再被使用的。

很多主流的java虚拟机里面没有选用引用技术算法来管理内存，主要的原因就是： 它很难解决对象之间相互循环引用的问题

2. 可达性分析算法

该算法的基本思路：
通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象的GC Roots没有任何引用链相连时，则证明此对象是不可用的

在java语言中，可作为GC Roots的对象包括以下几种：

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

再谈引用

在JDK 1.2以后，java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

1. 强引用（Strong Reference）

如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，JVM宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会随意回收具有强引用的对象来解决内存不足的问题。

强引用的例子：

Object obj = new Object();

2. 软引用（Soft Reference）

如果一个对象只具有软引用，则内存空间足够，垃圾收集器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。

弱引用的例子：

MyObject aReference = new MyObject();
SoftReference aSoftReference = new SoftReference(aReference)；

此时，对于这个MyObject对象，有两个引用路径，一个是来自SoftReference对象的软引用，一个来自变量aReference的强引用，所以这个MyObject对象是强可及对象。

之后，我们结束aReference对这个MyObject的强引用

aReference = null；

执行完上述操作后，这个对象成为了软可及对象。如果垃圾收集线程进行内存垃圾收集，并不会因为有一个SoftReference对该对象的引用而始终保留该对象。JVM的垃圾收集线程对软可及对象和其他一般java对象进行了区别对待：软可及对象的清理时由垃圾收集线程根据其特定算法按照内存需求决定的。即，垃圾收集线程会在虚拟机抛出OutOfMemoryError之前回收软可及对象，而且虚拟机会尽可能优先回收长时间闲置不用的软可及对象，对那些刚刚构建的或者刚刚使用过的“新”软可及对象会被JVM尽可能保留。

使用ReferenceQueue清除失去了软引用对象的SoftReference

作为一个java对象，SoftReference对象除了具有保存软引用的特殊性之外，也具有java对象的一般性。所以，当软可及对象被回收后，虽然这个SoftReference对象的get()方法返回null，但这个SoftReference对象已经不再具有存在的价值，需要一个适当的清除机制，避免大量的SoftReference对象带来的内存泄漏。在java.lang.ref包里还提供了ReferenceQueue。如果在创建SoftReference对象的时候，使用了一个ReferenceQueue对象作为参数提供给SoftReference的构造方法

ReferenceQueue queue = new ReferenceQueue();

SoftReference ref = new SoftReference(aMyObject, queue); 

那么当这个SoftReference所软引用的aMyOhject被垃圾收集器回收的同时，ref所强引用的SoftReference对象被列入ReferenceQueue。也就是说，ReferenceQueue中保存的对象是Reference对象，而且是已经失去了它所软引用的对象的Reference对象。另外从ReferenceQueue这个名字也可以看出，它是一个队列，当我们调用它的poll()方法的时候，如果这个队列中不是空队列，那么将返回队列前面的那个Reference对象。
在任何时候，我们都可以调用ReferenceQueue的poll()方法来检查是否有它所关心的非强可及对象被回收。如果队列为空，将返回一个null,否则该方法返回队列中前面的一个Reference对象。利用这个方法，我们可以检查哪个SoftReference所软引用的对象已经被回收。于是我们可以把这些失去所软引用的对象的SoftReference对象清除掉。常用的方式为:

SoftReference ref = null;

while ((ref = (EmployeeRef) q.poll()) != null) {

// 清除ref

}

弱引用（Weak Reference）

被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

什么时候使用弱引用？

考虑下面的场景：现在有一个Product类代表一种产品，这个类被设计为不可扩展的，而此时我们想要为每一个产品增加一个编号。一种解决方案是使用HashMap。那么问题来了，如果我们已经不再需要一个Product对象存在于内存中（比如：已经卖出了这件产品），假设指向它的引用为productA，我们这时会给productA赋值为null，然而这时productA过去指向的Producr对象并不会被回收，因为它还被HashMap引用着。所以这种情况下，我们想要真正的回收一个Product对象，仅仅把它的强引用赋值为null是不够的，还要把相应的条目从HashMap中移除。显然“从HashMap中移除不再需要的条目”这个工作我们不想自己完成，我们希望垃圾收集器自己完成。

如何使用弱引用？

以上面的场景为例子：

Product productA = new Product();

WeakReference<Product> weakProductA = new WeakReference<>(productA);

现在，若弱引用对象weakProductA就指向了Product对象的productA，那么我们怎么通过weakProductA 来获取它所指向的Product对象productA呢？只需要下面的代码

Product product = weakProductA.get();

实际上，对于这种情况，Java类库为我们提供了WeakHashMap类，使用和这个类，它的键自然就是弱引用对象，无需我们再手动包装原始对象。这样一来，当productA变为null时（表明它所引用的Product已经无需存在于内存中），这时指向这个Product对象的就是由弱引用对象weakProductA了，那么显然这时候相应的Product对象时弱可达的，所以指向它的弱引用会被清除，这个Product对象随即会被回收，指向它的弱引用对象会进入引用队列中。

与软引用一样，弱引用也存在引用队列。

WeakReference类有两个构造函数：

//创建一个指向给定对象的弱引用
WeakReference（T referent）
//创建一个指向给定对象并且等级到给定引用队列的弱引用
WeakReference（T referent, ReferenceQueuesuper T> q）

我们可以看到第二个构造方法中提供了一个ReferenceQueue类型的参数，通过提供这个参数，我们便把创建的弱引用对象注册到了一个引用队列上，这样当它被垃圾回收器清楚时，就会把它送入这个引用队列中，我们便可以对这些被清楚的弱引用对象进行统一管理。

4. 虚引用

虚引用也成为幽灵引用或者幻影引用，它是最弱的一种引用关系。

垃圾收集过程中，对象的可触及状态改变的时候，可以把引用对象和引用队列关联起来。即垃圾收集器会把要回收的对象添加到引用队列ReferenceQueue

虚引用的作用：
我们可以生命虚引用来引用我们感兴趣的对象，在gc要回收的时候，gc收集器会把这个对象添加到ReferenceQueue，这样我们如果检查到ReferenceQueue中有我们感兴趣的对象的时候，说明gc将要回收这个对象了。此时我们可以在gc回收之前做一些其他事情，比如记录日志

在java中，finalize()函数本来是设计用来在对象被回收的时候来做一些操作的。但是对象被GC说明时候回收的时间是不固定的，这样finalize()函数很尴尬。虚引用可以用来解决这个问题。
在创建虚引用的时候必须传入一个引用队列。在一个对象finalize函数被调用之后，这个对象的幽灵引用会被假如到引用队列中。通过检查队列的内容就知道对象是不是要准备被回收了。
幽灵引用的使用并不常见，主要是实现细粒度的内存控制

示例：实现一个缓存。程序在确认原来的对象要被回收之后，才申请内存创建新的缓存。

import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

public class PhantomBuffer {
    private byte[] data= new byte[0];
    private ReferenceQueue<byte[]> queue = new ReferenceQueue<byte[]>();

    private PhantomReference<byte[]> ref = new PhantomReference<byte[]>(data,queue);

    public byte[] get(int size) {
        if(size <= 0) {
            throw new IllegalArgumentException("Wrong buffer size");
        }
        if(data.length < size) {
            data = null;
            //强行运行垃圾回收器，调用该方法只是建议JVM进行回收，并不一定马上会进行GC
            System.gc();
            try {
                //该方法会阻塞直到队列非空
                queue.remove();
                //幽灵引用不会自动清空，要手动运行
                ref.clear();
                ref = null;
                data = new byte[size];
                ref = new PhantomReference<byte[]>(data, queue);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }

        }
        return data;
    }
}

上述代码中，每次申请新的缓存的时候，都要确保之前的字节数组被成功回收。引用队列的remove方法会阻塞知道虚引用被假如到引用队列中。

对象的生存与死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

• 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。
• 如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环，将很可能会导致F-Queue队列中企鹅他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize（）方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize（）中成功成就自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那再第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
        System.out.println("yes, i am still alive:");
    }

    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();

        //对象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以暂停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();
        //因为finalize方法优先级很低，所以暂停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（）方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize（）方法不会被再次执行。

回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

废弃常量：回收废弃常量与回收java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池，但是当前系统没有任何一个String对象是叫做“abc”的，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。

废弃类：判断一个类是否是废弃类，需要下面3个条件才能算是“无用的类”

• 该类所有的实例都可以被回收，也就是java堆中不存在该类的任何实例
• 加载该类的ClassLoader已经被回收
• 该类对应的java.lang,Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

参考文章

https://blog.csdn.net/u011936381/article/details/11709245
http://www.importnew.com/21206.html
https://blog.csdn.net/imzoer/article/details/8044900