请点赞关注,你的支持对我意义重大。
🔥 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: null
ReferenceQueue 中大部分 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 层方法:
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 art
3.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
线程。
源码摘要如下:
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);
}
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 线程): 标记工作完成后,进行释放内存操作,这个过程相对耗时。
源码摘要如下:
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
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
// 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);
}
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
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 章 · 垃圾收集器与内存分配策略) —— 周志明 著
你的点赞对我意义重大!微信搜索公众号 [彭旭锐],希望大家可以一起讨论技术,找到志同道合的朋友,我们下次见!
执着于理想,纯粹于当下。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。