JVM 系列(5)吊打面试官:说一下 Java 的四种引用类型

·  阅读 2415
JVM 系列(5)吊打面试官:说一下 Java 的四种引用类型

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第6天,点击查看活动详情 

请点赞关注,你的支持对我意义重大。

🔥 Hi,我是小彭。本文已收录到 GitHub · AndroidFamily 中。这里有 Android 进阶成长知识体系,有志同道合的朋友,关注公众号 [彭旭锐] 带你建立核心竞争力。

前言

  • Java Reference 类型是与虚拟机垃圾回收机制密切相关的知识点,同时也是面试重要考点之一。 一般认为 Java 有四种 Reference(强引用 & 软引用 & 弱引用 & 虚引用),但是其实还有隐藏的第五种 Reference,你知道是什么吗?
  • 在这篇文章里,我将总结引用类型的用法 & 区别,并基于 ART 虚拟机分析相关源码。如果能帮上忙,请务必点赞加关注,这真的对我非常重要。

提示: 本文源码分析基于 Android 9.0 ART 虚拟机。


这篇文章是 JVM 系列文章第 5 篇,专栏文章列表:

一、内存管理:

二、编译链接过程

  • 1、Java 编译过程
  • 2、Class 文件格式
  • 3、注解处理器
  • 4、注解机制
  • 5、类加载机制
  • 6、泛型机制

三、执行系统

提示:很多内容都已经发表过了,最近会整理出来


学习路线图:


1. 认识 Java 引用

1.1 Java 四大引用类型

Java 引用是 Java 虚拟机为了实现更加灵活的对象生命周期管理而设计的对象包装类,一共有四种引用类型,分别是强引用、软引用、弱引用和虚引用。我将它们的区别概括为 3 个维度:

  • 维度 1 - 对象可达性状态的区别: 强引用指向的对象是强可达的,而其他引用指向的对象都是弱可达的。当一个对象存在到 GC Root 的引用链时,该对象被认为是强可达的。只有强可达的对象才会认为是存活的对象,才能保证在垃圾收集的过程中不会被回收;
  • 维度 2 - 垃圾回收策略的区别: 除了影响对象的可达性状态,不同的引用类型还会影响垃圾收集器回收对象的激进程度:
    • 强引用: 强引用指向的对象不会被垃圾收集器回收;
    • 软引用: 软引用是相对于强引用更激进的策略,软引用指向的对象在内存充足时会从垃圾收集器中豁免,起到类似强引用的效果,但在内存不足时还是会被垃圾收集器回收。那么软引用通常是用于实现内存敏感的缓存,当有足够空闲内存时保留内存,当空闲内存不足时清理缓存,避免缓存耗尽内存;
    • 弱引用和虚引用: 弱引用和虚引用是相对于软引用更激进的策略,弱引用指向的对象无论在内存是否充足的时候,都会被垃圾收集器回收;
  • 维度 3 - 感知垃圾回收时机: 虚引用主要的作用是提供了一个感知对象被垃圾回收的机制。在虚拟机即将回收对象之前,如果发现对象还存在虚引用,则会在回收对象后会将引用加入到关联的引用队列中。程序可以通过观察引用队列的方式,来感知到对象即将被垃圾回收的时机,再采取必要的措施。例如 Java Cleaner 工具类,就是基于虚引用实现的回收工具类。需要特别说明的是,并不是只有虚引用才能与引用队列关联,软引用和弱引用都可以与引用队列关联,只是说虚引用唯一的作用就是感知对象垃圾回收时机。

除了我们熟悉的四大引用,虚拟机内部还设计了一个 @hideFinalizerReference 引用,用于支持 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 层方法:

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 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 线程。

源码摘要如下:

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 机制是不稳定和危险的。


参考资料

你的点赞对我意义重大!微信搜索公众号 [彭旭锐],希望大家可以一起讨论技术,找到志同道合的朋友,我们下次见!

执着于理想,纯粹于当下。

分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改