请点赞关注，你的反对对我意义重大。
🔥 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@3286da7
I/System.out: null
I/System.out: weakRef 2:java.lang.ref.WeakReference@3286da7
I/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::DelayReferenceReferent
reference_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#ClearWhiteReferences
reference_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#Run
reference_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 章 · 垃圾收集器与内存调配策略）—— 周志明 著
你的点赞对我意义重大！微信搜寻公众号 [彭旭锐]，心愿大家能够一起探讨技术，找到气味相投的敌人，咱们下次见！
执着于现实，纯正于当下。