请点赞关注，你的反对对我意义重大。
Hi，我是小彭。本文已收录到 GitHub · AndroidFamily 中。这里有 Android 进阶成长常识体系，有气味相投的敌人，关注公众号 [彭旭锐] 带你建设外围竞争力。
前言
- Java Reference 类型是与虚拟机垃圾回收机制密切相关的知识点，同时也是面试重要考点之一。 个别认为 Java 有四种 Reference（强援用 & 软援用 & 弱援用 & 虚援用），然而其实还有暗藏的第五种 Reference，你晓得是什么吗？
- 在这篇文章里，我将总结援用类型的用法 & 区别，并基于 ART 虚拟机剖析相干源码。如果能帮上忙，请务必点赞加关注，这真的对我十分重要。
提醒： 本文源码剖析基于 Android 9.0 ART 虚拟机。
学习路线图：
1. 意识 Java 援用
1.1 Java 四大援用类型
Java 援用是 Java 虚拟机为了实现更加灵便的对象生命周期治理而设计的对象包装类，一共有四种援用类型，别离是强援用、软援用、弱援用和虚援用。我将它们的区别概括为 3 个维度：
- 维度 1 - 对象可达性状态的区别： 强援用指向的对象是强可达的，而其余援用指向的对象都是弱可达的。当一个对象存在到 GC Root 的援用链时，该对象被认为是强可达的。只有强可达的对象才会认为是存活的对象，能力保障在垃圾收集的过程中不会被回收；
维度 2 - 垃圾回收策略的区别： 除了影响对象的可达性状态，不同的援用类型还会影响垃圾收集器回收对象的激进水平：
- 强援用： 强援用指向的对象不会被垃圾收集器回收；
- 软援用： 软援用是绝对于强援用更激进的策略，软援用指向的对象在内存短缺时会从垃圾收集器中豁免，起到相似强援用的成果，但在内存不足时还是会被垃圾收集器回收。那么软援用通常是用于实现内存敏感的缓存，当有足够闲暇内存时保留内存，当闲暇内存不足时清理缓存，防止缓存耗尽内存；
- 弱援用和虚援用： 弱援用和虚援用是绝对于软援用更激进的策略，弱援用指向的对象无论在内存是否短缺的时候，都会被垃圾收集器回收；
- 维度 3 - 感知垃圾回收机会： 虚援用次要的作用是提供了一个感知对象被垃圾回收的机制。在虚拟机行将回收对象之前，如果发现对象还存在虚援用，则会在回收对象后会将援用退出到关联的援用队列中。程序能够通过观察援用队列的形式，来感知到对象行将被垃圾回收的机会，再采取必要的措施。例如 Java Cleaner 工具类，就是基于虚援用实现的回收工具类。须要特地阐明的是，并不是只有虚援用能力与援用队列关联，软援用和弱援用都能够与援用队列关联，只是说虚援用惟一的作用就是感知对象垃圾回收机会。
除了咱们相熟的四大援用，虚拟机外部还设计了一个 @hide 的FinalizerReference 援用，用于反对 Java Finalizer 机制，更多内容见 Finalizer 机制。
1.2 指针、援用和句柄有什么区别？
援用、指针和句柄都具备指向对象地址的含意，能够将它们都简略地了解为一个内存地址。只有在具体的问题中，才须要辨别它们的含意：
- 1、援用（Reference）： 援用是 Java 虚拟机为了实现灵便的对象生命周期治理而实现的对象包装类，援用自身并不持有对象数据，而是通过间接指针或句柄 2 种形式来拜访真正的对象数据；
- 2、指针（Point）： 指针也叫间接指针，它示意对象数据在内存中的地址，通过指针就能够间接拜访对象数据；
- 3、句柄（Handler）： 句柄是一种非凡的指针，句柄持有指向对象实例数据和类型数据的指针。应用句柄的长处是让对象在垃圾收集的过程中挪动存储区域的话，虚拟机只须要扭转句柄中的指针，而援用持有的句柄是稳固的。毛病是须要两次指针拜访能力拜访到对象数据。
间接指针拜访：
句柄拜访：
2. 援用应用办法
这一节咱们来探讨如何将援用与援用队列的应用办法。
2.1 应用援用对象
- 1、创立援用对象： 间接通过结构器创立援用对象，并且间接在结构器中传递关联的理论对象和援用队列。援用队列能够为空，但虚援用必须关联援用队列，否则没有意义；
- 2、获取理论对象： 在理论对象被垃圾收集器回收之前，通过
Reference#get()能够获取理论对象，在理论对象被回收之后 get() 将返回 null，而虚援用调用 get() 办法永远是返回 null； - 3、解除关联关系： 调用
Reference#clear()能够提前解除关联关系。
get() 和 clear() 最终是调用 native 办法，咱们在后文剖析。
SoftReference.java
// 已简化public class SoftReference<T> extends Reference<T> { public SoftReference(T referent) { super(referent); } public SoftReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); }}WeakReference.java
public class WeakReference<T> extends Reference<T> { public WeakReference(T referent) { super(referent); } public WeakReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); }}PhantomReference.java
public class PhantomReference<T> extends Reference<T> { // 虚援用 get() 永远返回 null public T get() { return null; } // 虚援用必须治理援用队列，否则没有意义 public PhantomReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); }}Reference.java
// 援用对象公共父类public abstract class Reference<T> { // 虚拟机外部应用 volatile T referent; // 关联援用队列 final ReferenceQueue<? super T> queue; Reference(T referent) { this(referent, null); } Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; this.queue = queue; } // 获取援用指向的理论对象 public T get() { // 调用 Native 办法 return getReferent(); } @FastNative private final native T getReferent(); // 解除援用与理论对象的关联关系 public void clear() { // 调用 Native 办法 clearReferent(); } @FastNative native void clearReferent(); ...}2.2 援用队列应用模板
以下为 ReferenceQueue 的应用模板，次要分为 2 个阶段：
- 阶段 1： 创立援用队列实例，并在创立援用对象时关联该队列；
- 阶段 2： 对象在被垃圾回收后，援用对象会被退出援用队列（依据下文源码剖析，援用对象在进入援用队列的时候，理论对象曾经被回收了）。通过观察
ReferenceQueue#poll()的返回值能够感知对象垃圾回收的机会。
示例程序
// 阶段 1：// 创建对象String strongRef = new String("abc");// 1、创立援用队列ReferenceQueue<String> referenceQueue = new ReferenceQueue<>();// 2、创立援用对象，并关联援用队列WeakReference<String> weakRef = new WeakReference<>(strongRef, referenceQueue);System.out.println("weakRef 1:" + weakRef);// 3、断开强援用strongRef = null;System.gc();// 阶段 2：// 延时 5000 是为了进步 "abc" 被回收的概率view.postDelayed(new Runnable() { @Override public void run() { System.out.println(weakRef.get()); // 输入 null // 察看援用队列 Reference<? extends String> ref = referenceQueue.poll(); if (null != ref) { System.out.println("weakRef 2:" + ref); // 尽管能够获取到 Reference 对象，但无奈获取到援用本来指向的对象 System.out.println(ref.get()); // 输入 null } }}, 5000);程序输入
I/System.out: weakRef 1:java.lang.ref.WeakReference@3286da7I/System.out: nullI/System.out: weakRef 2:java.lang.ref.WeakReference@3286da7I/System.out: nullReferenceQueue 中大部分 API 是面向 Java 虚拟机外部的，只有 ReferenceQueue#poll() 是面向开发者的。它是非阻塞 API，在队列有数据时返回队头的数据，而在队列为空时间接返回 null。
ReferenceQueue.java
public Reference<? extends T> poll() { synchronized (lock) { if (head == null) return null; return reallyPollLocked(); }}2.3 工具类 Cleaner 应用模板
Cleaner 是虚援用的工具类，用于实现在对象被垃圾回收时额定执行一段清理逻辑，实质上只是将虚援用和援用队列等代码做了简略封装而已。以下为 Cleaner 的应用模板：
示例程序
// 1、创建对象String strongRef = new String("abc");// 2、创立清理逻辑CleanerThunk thunk = new CleanerThunk();// 3、创立 Cleaner 对象（实质上是一个虚援用）Cleaner cleaner = Cleaner.create(strongRef, thunk);private class CleanerThunk implements Runnable { @Override public void run() { // 清理逻辑 }}Cleaner.java
// Cleaner 只不过是虚援用的工具类而已public class Cleaner extends PhantomReference<Object> { ...}3. 援用实现原理剖析
从这一节开始，咱们来深入分析 Java 援用的实现原理，相干源码基于 Android 9.0 ART 虚拟机。
3.1 ReferenceQueue 数据结构
ReferenceQueue 是基于单链表实现的队列，元素依照先进先出的程序出队（Java OpenJDK 和 Android 中的 ReferenceQueue 实现略有区别，OpenJDK 以先进后出的程序出队，而 Android 以先进先出的程序出队）。
Reference.java
public abstract class Reference<T> { // 关联的援用队列 final ReferenceQueue<? super T> queue; // 单链表后继指针 Reference queueNext;}ReferenceQueue.java
public class ReferenceQueue<T> { // 入队 boolean enqueue(Reference<? extends T> reference) { synchronized (lock) { if (enqueueLocked(reference)) { lock.notifyAll(); return true; } return false; } } // 出队 public Reference<? extends T> poll() { synchronized (lock) { if (head == null) return null; return reallyPollLocked(); } } // 入队 private boolean enqueueLocked(Reference<? extends T> r) { // 解决 Cleaner 逻辑 if (r instanceof Cleaner) { Cleaner cl = (sun.misc.Cleaner) r; cl.clean(); r.queueNext = sQueueNextUnenqueued; return true; } // 尾插法 if (tail == null) { head = r; } else { tail.queueNext = r; } tail = r; tail.queueNext = r; return true; } // 出队 private Reference<? extends T> reallyPollLocked() { if (head != null) { Reference<? extends T> r = head; if (head == tail) { tail = null; head = null; } else { head = head.queueNext; } r.queueNext = sQueueNextUnenqueued; return r; } return null; }}3.2 援用对象与理论对象的关联
在上一节咱们提到 Reference#get() 和 Reference#clear() 能够获取或解除关联关系，它们是在 Native 层实现的。最终能够看到关联关系是在 ReferenceProcessor 中保护的，ReferenceProcessor外部咱们先不剖析了。
对应的 Native 层办法：
java_lang_ref_Reference.cc
namespace art {// 对应 Java native 办法 Reference#getReferent() static jobject Reference_getReferent(JNIEnv* env, jobject javaThis) { ScopedFastNativeObjectAccess soa(env); ObjPtr<mirror::Reference> ref = soa.Decode<mirror::Reference>(javaThis); ObjPtr<mirror::Object> const referent = Runtime::Current()->GetHeap()->GetReferenceProcessor()->GetReferent(soa.Self(), ref); return soa.AddLocalReference<jobject>(referent);}// 对应 Java native 办法 Reference#clearReferent()static void Reference_clearReferent(JNIEnv* env, jobject javaThis) { ScopedFastNativeObjectAccess soa(env); ObjPtr<mirror::Reference> ref = soa.Decode<mirror::Reference>(javaThis); Runtime::Current()->GetHeap()->GetReferenceProcessor()->ClearReferent(ref);}// 动静注册 JNI 函数static JNINativeMethod gMethods[] = { FAST_NATIVE_METHOD(Reference, getReferent, "()Ljava/lang/Object;"), FAST_NATIVE_METHOD(Reference, clearReferent, "()V"),};void register_java_lang_ref_Reference(JNIEnv* env) { REGISTER_NATIVE_METHODS("java/lang/ref/Reference");}} // namespace art3.3 援用对象入队过程剖析
援用对象退出援用队列的过程产生在垃圾收集器的处理过程中，我将相干流程概括为 2 个阶段：
- 阶段 1： 在垃圾收集的标记阶段，垃圾收集器会标记在本次垃圾收集中豁免的对象（包含强援用对象、FinalizerReference 对象以及不须要在本次回收的 SoftReference 软援用对象）。当一个援用对象指向的理论对象没有被标记时，阐明该对象除了被援用对象援用之外曾经不存在其余援用关系。那么垃圾收集器会解除援用对象与理论对象的关联关系，并且将援用对象暂存到一个全局链表
unenqueued中，随后 notify 正在期待类对象的线程 （阶段 1 理论的处理过程更简单，咱们稍后再详细分析）；
ReferenceQueue.java
// 长期的全局链表public static Reference<?> unenqueued = null;// 从 Native 层调用static void add(Reference<?> list) { synchronized (ReferenceQueue.class) { // 此处应用尾插法将 list 退出全局链表 unenqueued，代码略 // 唤醒期待类锁的线程 ReferenceQueue.class.notifyAll(); }}那么，谁在期待这个类对象呢？其实，在虚拟机启动时，会启动一系列守护线程，其中就包含解决援用入队的 ReferenceQueueDaemon 线程和 Finalizer 机制的 FinalizerDaemon 线程，这里唤醒的正是ReferenceQueueDaemon 线程。
源码摘要如下：
runtime.cc
void Runtime::StartDaemonThreads() { // 调用 java.lang.Daemons.start() Thread* self = Thread::Current(); JNIEnv* env = self->GetJniEnv(); env->CallStaticVoidMethod(WellKnownClasses::java_lang_Daemons, WellKnownClasses::java_lang_Daemons_start);}Daemons.java
public static void start() { // 启动四个守护线程： // ReferenceQueueDaemon：解决援用入队 ReferenceQueueDaemon.INSTANCE.start(); // FinalizerDaemon：解决 Finalizer 机制 FinalizerDaemon.INSTANCE.start(); FinalizerWatchdogDaemon.INSTANCE.start(); HeapTaskDaemon.INSTANCE.start();}- 阶段 2：
ReferenceQueueDaemon线程会应用期待唤醒机制轮询生产这个全局链表unenqueued，如果链表不为空则将援用对象投递到对应的援用队列中，否则线程会进入期待。
Daemons.java
private static class ReferenceQueueDaemon extends Daemon { private static final ReferenceQueueDaemon INSTANCE = new ReferenceQueueDaemon(); ReferenceQueueDaemon() { super("ReferenceQueueDaemon"); } // 阶段 2：轮询 unenqueued 全局链表 @Override public void runInternal() { while (isRunning()) { Reference<?> list; // 2.1 同步块 synchronized (ReferenceQueue.class) { // 2.2 查看 unenqueued 全局链表是否为空 while (ReferenceQueue.unenqueued == null) { // 2.3 为空则期待 ReferenceQueue.class 类锁 ReferenceQueue.class.wait(); } list = ReferenceQueue.unenqueued; ReferenceQueue.unenqueued = null; } // 2.4 投递援用对象 // 为什么放在同步块之外：因为 list 曾经从动态变量 unenqueued 剥离解决，不必放心其余线程会插入新的援用，所以能够放在 synchronized{} 块之外 ReferenceQueue.enqueuePending(list); } }}private static class FinalizerDaemon extends Daemon { ...}ReferenceQueue.java
// 2.4 投递援用对象public static void enqueuePending(Reference<?> list) { Reference<?> start = list; do { ReferenceQueue queue = list.queue; if (queue == null) { // 2.4.1 没有关联的援用队列，则不须要投递 Reference<?> next = list.pendingNext; list.pendingNext = list; list = next; } else { // 2.4.2 为了防止重复加锁，这里抉择一次性投递雷同援用队列的对象 synchronized (queue.lock) { do { Reference<?> next = list.pendingNext; list.pendingNext = list; // 2.4.3 援用对象入队 queue.enqueueLocked(list); list = next; } while (list != start && list.queue == queue); // 2.4.4 唤醒 queue.lock，跟 remove(...) 无关 queue.lock.notifyAll(); } } } while (list != start);}至此，援用对象曾经退出 ReferenceQueue 中的双向链表，期待消费者调用 ReferenceQueue#poll() 生产援用对象。
应用一张示意图概括整个过程：
当初，咱们回过头来详细分析 阶段 1 中的执行过程： ART 虚拟机存在多种垃圾收集算法，咱们以 CMS 并发标记革除算法为例进行剖析。先简略回顾下 CMS 并发标记革除算法分为 4 个阶段：
- 初始标记（暂停 mutator 线程）： 仅仅标记被 GC Root 间接援用的对象，因为 GC Root 绝对较少，这个过程绝对比拟短；
- 并发标记（复原 mutator 线程）： 对初始标记失去的对象持续递归遍历，这个过程绝对耗时。因为此时 mutator 线程和 collector 线程是并发运行的，所以很可能会扭转对象的可达性状态，因而这里会记录 mutator 线程所做的批改；
- 重标记（暂停 mutator 线程）： 因为并发标记阶段可能会扭转对象的可达性状态，因而须要从新标记。然而并不是从新从 GC Root 递归遍历所有对象，而是会依据记录的批改行为放大追踪范畴，所以耗时绝对比拟短；
- 并发清理（复原 mutator 线程）： 标记工作实现后，进行开释内存操作，这个过程绝对耗时。
源码摘要如下：
mark_sweep.cc
void MarkSweep::RunPhases() { // 1、初始标记（只解决 GC Root 间接援用的对象） MarkRoots(self); // 2、并发标记（基于初始标记记录的可达对象） MarkReachableObjects(); // 3.1 重标记（只解决 GC Root 间接援用的对象） ReMarkRoots(); // 3.2 重标记（只解决并发标记记录的脏对象） RecursiveMarkDirtyObjects(true/* 是否暂停 */, ...); // 4. 并发革除 ReclaimPhase();}标记阶段： 在垃圾收集的并发标记阶段，会从 GC Root 进行递归遍历。每次找到一个援用类型对象，并且其指向的理论对象没有被标记（阐明该对象除了被援用对象援用之外曾经不存在其余援用关系），那么将该援用对象退出到 ReferenceProcessor 中对应的长期队列中。
办法调用链： MarkReachableObjects→RecursiveMark→ProcessMarkStack→ScanObject→DelayReferenceReferentVisitor#operator→DelayReferenceReferent→ReferenceProcessor::DelayReferenceReferentreference_processor.cc
void ReferenceProcessor::DelayReferenceReferent(ObjPtr<mirror::Class> klass, ObjPtr<mirror::Reference> ref, collector::GarbageCollector* collector) { mirror::HeapReference<mirror::Object>* referent = ref->GetReferentReferenceAddr(); // IsNullOrMarkedHeapReference：判断援用指向的理论对象是否被标记 if (!collector->IsNullOrMarkedHeapReference(referent, /*do_atomic_update*/true)) { Thread* self = Thread::Current(); // 不同援用类型别离退出不同的队列中 if (klass->IsSoftReferenceClass()) { // 软援用待处理队列 soft_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref); } else if (klass->IsWeakReferenceClass()) { // 弱援用待处理队列 weak_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref); } else if (klass->IsFinalizerReferenceClass()) { // Fianlizer 援用待处理队列 finalizer_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref); } else if (klass->IsPhantomReferenceClass()) { // 虚援用待处理队列 phantom_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref); } }}清理阶段： 在垃圾收集器清理阶段，顺次解决长期队列中的援用对象，解除援用对象与理论对象的关联关系，所有解绑的援用对象都会被记录到另一个长期队列 cleared_references_ 中。
办法调用链： ReclaimPhase→ProcessReferences→ReferenceProcessor::ProcessReferences→ReferenceQueue#ClearWhiteReferencesreference_processor.cc
// Process reference class instances and schedule finalizations.void ReferenceProcessor::ProcessReferences(bool concurrent, TimingLogger* timings, bool clear_soft_references, collector::GarbageCollector* collector) { ... // 软援用 soft_reference_queue_.ClearWhiteReferences(&cleared_references_, collector); // 弱援用 weak_reference_queue_.ClearWhiteReferences(&cleared_references_, collector); // FinalizeReference（EnqueueFinalizerReferences 在下篇文章剖析） finalizer_reference_queue_.EnqueueFinalizerReferences(&cleared_references_, collector); // 虚援用 phantom_reference_queue_.ClearWhiteReferences(&cleared_references_, collector);}reference_queue.cc
void ReferenceQueue::ClearWhiteReferences(ReferenceQueue* cleared_references, collector::GarbageCollector* collector) { while (!IsEmpty()) { ObjPtr<mirror::Reference> ref = DequeuePendingReference(); mirror::HeapReference<mirror::Object>* referent_addr = ref->GetReferentReferenceAddr(); // IsNullOrMarkedHeapReference：判断援用指向的理论对象是否被标记 if (!collector->IsNullOrMarkedHeapReference(referent_addr, /*do_atomic_update*/false)) { // 解除援用关系 ref->ClearReferent<false>(); // 退出另一个长期队列 cleared_references_ cleared_references->EnqueueReference(ref); } DisableReadBarrierForReference(ref); }}回收对象后： 在理论对象被回收后，调用最终会将长期队列 cleared_references 传递到 Java 层的静态方法 ReferenceQueue#add()，从而存储到 Java 层的 unenqueued 变量中，之后就是交给 ReferenceQueueDaemon 线程解决。
办法调用链： Heap::CollectGarbageInternal→ReferenceProcessor#EnqueueClearedReferences→ ClearedReferenceTask#Runreference_processor.cc
class ClearedReferenceTask : public HeapTask {public: explicit ClearedReferenceTask(jobject cleared_references) : HeapTask(NanoTime()), cleared_references_(cleared_references) { } virtual void Run(Thread* thread) { ScopedObjectAccess soa(thread); jvalue args[1]; // 调用 Java 层 ReferenceQueue#add 办法 args[0].l = cleared_references_; InvokeWithJValues(soa, nullptr, WellKnownClasses::java_lang_ref_ReferenceQueue_add, args); soa.Env()->DeleteGlobalRef(cleared_references_); }private: const jobject cleared_references_;};至此，阶段 1 剖析结束。
3.4 FinalizeReference 援用的解决
为了实现对象的 Finalizer 机制，虚拟机设计了 FinalizerReference 援用类型，FinalizeReference 援用的处理过程与其余援用类型是雷同的。次要区别在于 阶段 1 中解除援用对象与理论对象的关联关系后，会把理论对象暂存到 FinalizeReference 的 zombie 字段中。 阶段 2 的解决是完全相同的，ReferenceQueueDaemon 线程会将 FinalizeReference 投递到关联的援用对象中。随后，守护线程 FinalizerDaemon 会轮询察看援用队列，并执行理论对象上的 finalize() 办法。
更多内容分析，见 Finalizer 机制
4. 总结
小结以下援用治理中最次要的环节：
- 1、在理论对象被回收后，援用对象会暂存到全局长期队列
unenqueued队列； - 2、守护线程
ReferenceQueueDaemon会轮询unenqueued队列，将援用对象别离投递到关联的援用队列中； - 3、守护线程
FinalizerDaemon会轮询察看援用队列，并执行理论对象上的 finalize() 办法。
应用一张示意图概括整个过程：
下一篇文章里，咱们将更深刻地剖析 Java Finalizer 机制的实现原理，以及剖析 Finalizer 存在的问题。例如为什么 Finalizer 机制是不稳固和危险的。
参考资料
- Effective Java（第 3 版）（8. 防止应用 Finalizer 和 Cleanr 机制） —— [美] Joshua Bloch 著
- 深刻了解 Android：Java 虚拟机 ART（第 14 章 · ART 中的 GC） —— 邓凡平 著
- 深刻了解 Java 虚拟机（第 3 版）（第 3 章 · 垃圾收集器与内存调配策略） —— 周志明 著
你的点赞对我意义重大！微信搜寻公众号 [彭旭锐]，心愿大家能够一起探讨技术，找到气味相投的敌人，咱们下次见！
执着于现实，纯正于当下。