java 源码系列 - 带你读懂 Reference 和 ReferenceQueue

https://blog.csdn.net/gdutxiaoxu/article/details/80738581

一步步拆解 LeakCanary

https://blog.csdn.net/gdutxiaoxu/article/details/80752876

从基础讲起

Reference

主要是负责内存的一个状态，当然它还和java虚拟机，垃圾回收器打交道。Reference类首先把内存分为4种状态Active，Pending，Enqueued，Inactive。

Active，一般来说内存一开始被分配的状态都是 Active，
Pending 大概是指快要被放进队列的对象，也就是马上要回收的对象，
Enqueued 就是对象的内存已经被回收了，我们已经把这个对象放入到一个队列中，方便以后我们查询某个对象是否被回收，
Inactive就是最终的状态，不能再变为其它状态。

ReferenceQueue

引用队列，当检测到对象的可到达性更改时，垃圾回收器将已注册的引用对象添加到队列中，ReferenceQueue实现了入队（enqueue）和出队（poll），还有remove操作，内部元素head就是泛型的Reference。

简单例子

当我们想检测一个对象是否被回收了，那么我们就可以采用 Reference + ReferenceQueue，大概需要几个步骤：

创建一个引用队列 queue
创建 Reference 对象，并关联引用队列 queue
在 reference 被回收的时候，Reference 会被添加到 queue 中

创建一个引用队列
ReferenceQueue queue = new ReferenceQueue();  // 创建弱引用，此时状态为Active，并且Reference.pending为空，当前Reference.queue = 上面创建的queue，并且next=null
WeakReference reference = new WeakReference(new Object(), queue);
System.out.println(reference);
// 当GC执行后，由于是弱引用，所以回收该object对象，并且置于pending上，此时reference的状态为PENDING
System.gc();  /* ReferenceHandler从pending中取下该元素，并且将该元素放入到queue中，此时Reference状态为ENQUEUED，Reference.queue = ReferenceENQUEUED */  /* 当从queue里面取出该元素，则变为INACTIVE，Reference.queue = Reference.NULL */
Reference reference1 = queue.remove();
System.out.println(reference1);

那这个可以用来干什么了？

可以用来检测内存泄露， github 上面的 leekCanary 就是采用这种原理来检测的。

监听 Activity 的生命周期
在 onDestroy 的时候，创建相应的 Reference 和 ReferenceQueue，并启动后台进程去检测
一段时间之后，从 ReferenceQueue 读取，若读取不到相应 activity 的 Reference，有可能发生泄露了，这个时候，再促发 gc，一段时间之后，再去读取，若在从 ReferenceQueue 还是读取不到相应 activity 的 Reference，可以断定是发生内存泄露了
发生内存泄露之后，dump，分析 hprof 文件，找到泄露路径

Reference

主要内存成员变量

private T referent;
volatile ReferenceQueue<? super T> queue;  /* When active:   NULL *     pending:   this *    Enqueued:   next reference in queue (or this if last) *    Inactive:   this */
@SuppressWarnings("rawtypes")
Reference next;  transient private Reference<T> discovered;  /* used by VM */  /* List of References waiting to be enqueued.  The collector adds* References to this list, while the Reference-handler thread removes* them.  This list is protected by the above lock object. The* list uses the discovered field to link its elements.*/
private static Reference<Object> pending = null;

referent表示其引用的对象，即在构造的时候需要被包装在其中的对象。
queue 是对象即将被回收时所要通知的队列。当对象即将被回收时，整个reference对象，而不仅仅是被回收的对象，会被放到queue 里面，然后外部程序即可通过监控这个 queue 即可拿到相应的数据了。
next 即当前引用节点所存储的下一个即将被处理的节点。但 next 仅在放到queue中才会有意义，因为只有在enqueue的时候，会将next设置为下一个要处理的Reference对象。为了描述相应的状态值，在放到队列当中后，其queue就不会再引用这个队列了。而是引用一个特殊的 ENQUEUED（内部定义的一个空队列）。因为已经放到队列当中，并且不会再次放到队列当中。
discovered 表示要处理的对象的下一个对象。即可以理解要处理的对象也是一个链表，通过discovered进行排队，这边只需要不停地拿到pending，然后再通过discovered 不断地拿到下一个对象赋值给pending即可，直到取到了最有一个。它是被JVM 使用的。
pending 是等待被入队的引用列表。JVM 收集器会添加引用到这个列表，直到Reference-handler线程移除了它们。这个列表使用 discovered 字段来连接它下一个元素（即 pending 的下一个元素就是discovered对象。r = pending; pending = r.discovered）。

接下来，我们来看一下 Reference 的静态代码块

static {ThreadGroup tg = Thread.currentThread().getThreadGroup();for (ThreadGroup tgn = tg;tgn != null;tg = tgn, tgn = tg.getParent());Thread handler = new ReferenceHandler(tg, "Reference Handler");/* If there were a special system-only priority greater than* MAX_PRIORITY, it would be used here*/handler.setPriority(Thread.MAX_PRIORITY);handler.setDaemon(true);handler.start();// provide access in SharedSecretsSharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {@Overridepublic boolean tryHandlePendingReference() {return tryHandlePending(false);}});
}

我们，当 Reference 类被加载的时候，会执行静态代码块。在静态代码块里面，会启动 ReferenceHandler 线程,并设置线程的级别为最大级别， Thread.MAX_PRIORITY。

接下来我们来看一下 ReferenceHandler 这个类，可以看到 run 方法里面是一个死循环，我们主要关注 tryHandlePending 方法就 Ok 了

private static class ReferenceHandler extends Thread {----- // 核心代码如下public void run() {while (true) {tryHandlePending(true);}}
}

static boolean tryHandlePending(boolean waitForNotify) {Reference<Object> r;Cleaner c;try {synchronized (lock) {// 检查 pending 是否为 null，不为 null，制定 pending enqueueif (pending != null) {r = pending;// 'instanceof' might throw OutOfMemoryError sometimes// so do this before un-linking 'r' from the 'pending' chain...c = r instanceof Cleaner ? (Cleaner) r : null;// unlink 'r' from 'pending' chainpending = r.discovered;r.discovered = null;} else { // 为 null。等待// The waiting on the lock may cause an OutOfMemoryError// because it may try to allocate exception objects.if (waitForNotify) {lock.wait();}// retry if waitedreturn waitForNotify;}}} catch (OutOfMemoryError x) {// Give other threads CPU time so they hopefully drop some live references// and GC reclaims some space.// Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above// persistently throws OOME for some time...Thread.yield();// retryreturn true;} catch (InterruptedException x) {// retryreturn true;}// Fast path for cleanersif (c != null) {c.clean();return true;}ReferenceQueue<? super Object> q = r.queue;if (q != ReferenceQueue.NULL) q.enqueue(r);return true;
}

在 tryHandlePending 方法里面，检查 pending 是否为 null，如果pending不为 null，则将 pending 进行 enqueue，否则线程进入 wait 状态。

问题来了，我们从 Reference 源码中发现没有给 discovered和 pending 赋值的地方，那 pending和 discovered 到底是谁给他们赋值的。

我们回头再来看一下注释：简单来说，垃圾回收器会把 References 添加进入，Reference-handler thread 会移除它，即 discovered和 pending 是由垃圾回收器进行赋值的。

/* List of References waiting to be enqueued.  The collector adds* References to this list, while the Reference-handler thread removes* them.  This list is protected by the above lock object. The* list uses the discovered field to link its elements.*/
private static Reference<Object> pending = null;

ReferenceQueue

接下来，我们在来看一下 ReferenceQueue 的 enqueue 方法

boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */synchronized (lock) {// Check that since getting the lock this reference hasn't already been// enqueued (and even then removed)ReferenceQueue<?> queue = r.queue;// queue 为 null 或者 queue 已经被回收了，直接返回if ((queue == NULL) || (queue == ENQUEUED)) {return false;}assert queue == this;// 将 Reference 的状态置为 Enqueued，表示已经被回收r.queue = ENQUEUED;// 接着，将 Reference 插入到链表// 判断当前链表是否为 null，不为 null，将 r.next 指向 head，为 null，head 直接指向 rr.next = (head == null) ? r : head;// head 指针指向 rhead = r;queueLength++;if (r instanceof FinalReference) {sun.misc.VM.addFinalRefCount(1);}lock.notifyAll();return true;}
}

判断 queue 为 null 或者 queue 已经被回收了，直接返回
若 queue 不为 null，将 r (Reference) 的状态置为 Enqueued，表示已经被回收
将 Reference 插入到 queue 的头部

Reference 和 ReferenceQueue 的源码分析到此为止

Reference 的子类

4种引用
我们都知道在Java中有4种引用，这四种引用从高到低分别为：

StrongReference

这个引用在Java中没有相应的类与之对应，但是强引用比较普遍，例如：Object obj = new Object();这里的obj就是要给强引用，如果一个对象具有强引用，则垃圾回收器始终不会回收此对象。当内存不足时，JVM情愿抛出OOM异常使程序异常终止也不会靠回收强引用的对象来解决内存不足的问题。

SoftReference

如果一个对象只有软引用，则在内存充足的情况下是不会回收此对象的，但是，在内部不足即将要抛出OOM异常时就会回收此对象来解决内存不足的问题。

public class TestSoftReference {private static ReferenceQueue<Object> rq = new ReferenceQueue<Object>();public static void main(String[] args){Object obj = new Object();SoftReference<Object> sf = new SoftReference(obj,rq);System.out.println(sf.get()!=null);System.gc();obj = null;System.out.println(sf.get()!=null);}}

运行结果均为：true。

这也就说明了当内存充足的时候一个对象只有软引用也不会被JVM回收。

WeakReference

WeakReference 基本与SoftReference 类似，只是回收的策略不同。

只要 GC 发现一个对象只有弱引用，则就会回收此弱引用对象。但是由于GC所在的线程优先级比较低，不会立即发现所有弱引用对象并进行回收。只要GC对它所管辖的内存区域进行扫描时发现了弱引用对象就进行回收。

看一个例子：

public class TestWeakReference {private static ReferenceQueue<Object> rq = new ReferenceQueue<Object>();public static void main(String[] args) {Object obj = new Object();WeakReference<Object> wr = new WeakReference(obj,rq);System.out.println(wr.get()!=null);obj = null;System.gc();System.out.println(wr.get()!=null);//false，这是因为WeakReference被回收}}

运行结果为： true 、false

在指向 obj = null 语句之前，Object对象有两条引用路径，其中一条为obj强引用类型，另一条为wr弱引用类型。此时无论如何也不会进行垃圾回收。当执行了obj = null.Object 对象就只具有弱引用，并且我们进行了显示的垃圾回收。因此此具有弱引用的对象就被GC给回收了。

PhantomReference

PhantomReference，即虚引用，虚引用并不会影响对象的生命周期。虚引用的作用为：跟踪垃圾回收器收集对象这一活动的情况。

当GC一旦发现了虚引用对象，则会将PhantomReference对象插入ReferenceQueue队列，而此时PhantomReference对象并没有被垃圾回收器回收，而是要等到ReferenceQueue被你真正的处理后才会被回收。

注意：PhantomReference必须要和ReferenceQueue联合使用，SoftReference和WeakReference可以选择和ReferenceQueue联合使用也可以不选择，这使他们的区别之一。

接下来看一个虚引用的例子。

public class TestPhantomReference {private static ReferenceQueue<Object> rq = new ReferenceQueue<Object>();public static void main(String[] args){Object obj = new Object();PhantomReference<Object> pr = new PhantomReference<Object>(obj, rq);System.out.println(pr.get());obj = null;System.gc();System.out.println(pr.get());Reference<Object> r = (Reference<Object>)rq.poll();if(r!=null){System.out.println("回收");}}}

运行结果:null null 回收

根据上面的例子有两点需要说明：

PhantomReference的get方法无论在上面情况下都是返回null。这个在PhantomReference源码中可以看到。
在上面的代码中，如果obj被置为null，当GC发现虚引用，GC会将把 PhantomReference 对象pr加入到队列ReferenceQueue中，注意此时pr所指向的对象并没有被回收，在我们现实的调用了 rq.poll() 返回 Reference 对象之后当GC第二次发现虚引用，而此时 JVM 将虚引用pr插入到队列 rq 会插入失败，此时 GC 才会对虚引用对象进行回收。

总结

Reference 和引用队列 ReferenceQueue 联合使用时，如果 Reference 持有的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。