JVM 系列（5）吊打面试官：说一下 Java 的四种引用类型

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

🔥 Hi，我是小彭。本文已收录到 GitHub · AndroidFamily^[1] 中。这里有 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 层方法：

java_lang_ref_Reference.cc^[2]

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^[3]

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^[4]

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^[5]

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^[6]

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^[7]

// 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^[8]

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^[9]

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 机制）^[10] —— [美] Joshua Bloch 著
• 深入理解 Android：Java 虚拟机 ART（第 14 章 · ART 中的 GC）^[11] —— 邓凡平 著
• 深入理解 Java 虚拟机（第 3 版）（第 3 章 · 垃圾收集器与内存分配策略）^[12] —— 周志明 著

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

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

参考资料