JVM 系列（6）吊打面试官：为什么 finalize() 方法只会执行一次？

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

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

前言

Java Finalizer 机制提供了一个在对象被回收之前释放占用资源的时机，但是都说 Finalizer 机制是不稳定且危险的，不推荐使用，这是为什么呢？今天我们来深入理解这个问题。

学习路线图：

---

1. 认识 Finalizer 机制

1.1 为什么要使用 Finalizer 机制？

Java 的 Finalizer 机制的作用在一定程度上是跟 C/C++ 析构函数类似的机制。当一个对象的生命周期即将终结时，也就是即将被垃圾收集器回收之前，虚拟机就会调用对象的 finalize() 方法，从而提供了一个释放资源的时机。

1.2 Finalizer 存在的问题

虽然 Java Finalizer 机制是起到与 C/C++ 析构函数类似的作用，但两者的定位是有差异的。C/C++ 析构函数是回收对象资源的正常方式，与构造函数是一一对应的，而 Java Finalizer 机制是不稳定且危险的，不被推荐使用的，因为 Finalizer 机制存在以下 3 个问题：

• 问题 1 - Finalizer 机制执行时机不及时： 由于执行 Finalizer 机制的线程是一个守护线程，它的执行优先级是比用户线程低的，所以当一个对象变为不可达对象后，不能保证一定及时执行它的 finalize() 方法。因此，当大量不可达对象的 Finalizer 机制没有及时执行时，就有可能造成大量资源来不及释放，最终耗尽资源；
• 问题 2 - Finalizer 机制不保证执行： 除了执行时机不稳定，甚至不能保证 Finalizer 机制一定会执行。当程序结束后，不可达对象上的 Finalizer 机制有可能还没有运行。假设程序依赖于 Finalizer 机制来更新持久化状态，例如释放数据库的锁，就有可能使得整个分布式系统陷入死锁；
• 问题 3 - Finalizer 机制只会执行一次： 如果不可达对象在 finalize() 方法中被重新启用为可达对象，那么在它下次变为不可达对象后，不会再次执行 finalize() 方法。这与 Finalizer 机制的实现原理有关，后文我们将深入虚拟机源码，从源码层面深入理解。

1.3 什么时候使用 Finalizer 机制？

由于 Finalizer 机制存在不稳定性，因此不应该将 Finalizer 机制作为释放资源的主要策略，而应该作为释放资源的兜底策略。程序应该在不使用资源时主动释放资源，或者实现 AutoCloseable 接口并通过 try-with-resources 语法确保在有异常的情况下依然会释放资源。而 Finalizer 机制作为兜底策略，虽然不稳定但也好过忘记释放资源。

不过，Finalizer 机制已经被标记为过时，使用 Cleaner 机制作为释放资源的兜底策略（本质上是 PhantomReference 虚引用）是相对更好的选择。虽然 Cleaner 机制也存在相同的不稳定性，但总体上比 Finalizer 机制更好。

---

2. Finalizer 机制原理分析

从这一节开始，我们来深入分析 Java Finalizer 机制的实现原理，相关源码基于 Android 9.0 ART 虚拟机。

2.1 引用实现原理回顾

在上一篇文章中，我们分析过 Java 引用类型的实现原理，Java Finalizer 机制也是其中的一个环节，我们先对整个过程做一次简单回顾。

2.2 创建 FinalizerReference 引用对象

我们都知道 Java 有四大引用类型，除此之外，虚拟机内部还设计了 @hide 的 FinalizerReference 类型来支持 Finalizer 机制。Reference 引用对象是用来实现更加灵活的对象生命周期管理而设计的对象包装类，Finalizer 机制也与对象的生命周期有关，因此存在这样 “第 5 种引用类型” 也能理解。

在虚拟机执行类加载的过程中，会将重写了 Object#finalize() 方法的类型标记为 finalizable 类型。每次在创建标记为 finalizable 的对象时，虚拟机内部会同时创建一个关联的 FinalizerReference 引用对象，并将其暂存到一个全局的链表中 （如果不存在全局的变量中，没有强引用持有的 FinalizerReference 本身在下次 GC 直接就被回收了）。

heap.cc

void Heap::AddFinalizerReference(Thread* self, ObjPtr<mirror::Object>* object) {
    ScopedObjectAccess soa(self);
    ScopedLocalRef<jobject> arg(self->GetJniEnv(), soa.AddLocalReference<jobject>(*object));
    jvalue args[1];
    args[0].l = arg.get();
    // 调用 Java 层静态方法 FinalizerReference#add
    InvokeWithJValues(soa, nullptr, WellKnownClasses::java_lang_ref_FinalizerReference_add, args);
    *object = soa.Decode<mirror::Object>(arg.get());
}

FinalizerReference.java

// 关联的引用队列
public static final ReferenceQueue<Object> queue = new ReferenceQueue<Object>();
// 全局链表头指针（使用一个双向链表持有 FinalizerReference，否则没有强引用的话引用对象本身直接就被回收了）
private static FinalizerReference<?> head = null;

private FinalizerReference<?> prev;
private FinalizerReference<?> next;

// 从 Native 层调用
public static void add(Object referent) {
    // 创建 FinalizerReference 引用对象，并关联引用队列
    FinalizerReference<?> reference = new FinalizerReference<Object>(referent, queue);
    synchronized (LIST_LOCK) {
        // 头插法加入全局单链表
        reference.prev = null;
        reference.next = head;
        if (head != null) {
            head.prev = reference;
        }
        head = reference;
    }
}

public static void remove(FinalizerReference<?> reference) {
    // 从双向链表中移除，代码略
}

2.3 在哪里执行 finalize() 方法？

根据我们对引用队列的理解，当我们在创建引用对象时关联引用队列，可以实现感知对象回收时机的作用。当引用指向的实际对象被垃圾回收后，引用对象会被加入引用队列。那么，是谁在消费这个引用队列呢？

在虚拟机启动时，会启动一系列守护线程，其中除了处理引用入队的 ReferenceQueueDaemon 线程，还包括执行 Finalizer 机制的 FinalizerDaemon 线程。FinalizerDaemon 线程会轮询观察引用队列，并执行实际对象上的 finalize() 方法。

提示： FinalizerDaemon 是一个守护线程，因此 finalize() 的执行优先级低。

Daemons.java

public static void start() {
    // 启动四个守护线程
    ReferenceQueueDaemon.INSTANCE.start();
    FinalizerDaemon.INSTANCE.start();
    FinalizerWatchdogDaemon.INSTANCE.start();
    HeapTaskDaemon.INSTANCE.start();
}

// 已简化
private static class FinalizerDaemon extends Daemon {

    private static final FinalizerDaemon INSTANCE = new FinalizerDaemon();

    // 这个队列就是 FinalizerReference 关联的引用队列
    private final ReferenceQueue<Object> queue = FinalizerReference.queue;

    FinalizerDaemon() {
        super("FinalizerDaemon");
    }

    @Override public void runInternal() {
        while (isRunning()) {
            // 1、从引用队列中取出引用
            FinalizerReference<?> finalizingReference = (FinalizerReference<?>)queue.poll();
            // 2、执行引用所指向对象 Object#finalize()
            doFinalize(finalizingReference);
            // 提示：poll() 是非阻塞的，FinalizerDaemon 是与 FinalizerWatchDogDaemon 配合实现等待唤醒机制的
        }

    @FindBugsSuppressWarnings("FI_EXPLICIT_INVOCATION")
    private void doFinalize(FinalizerReference<?> reference) {
        // 2.1 移除 FinalizerReference 对象
        FinalizerReference.remove(reference);
        // 2.2 取出引用所指向的对象（不可思议，为什么不为空呢？）
        Object object = reference.get();
        // 2.3 解除关联关系
        reference.clear();
        // 2.4 调用 Object#finalize()
        object.finalize();
    }
}

这里你有发现问题吗，当普通的引用对象在进入引用队列时，虚拟机已经解除了引用对象与实际对象的关联，此时调用 Reference#get() 应该返回 null 才对。 但 FinalizerReference#get() 居然还能拿到实际对象，实际对象不是已经被回收了吗！？ 这只能从源码中寻找答案。

2.4 FinalizerReference 引用对象入队过程

由于标记为 finalizable 的对象在被回收之前需要调用 finalize() 方法，因此这一类对象的回收过程比较特殊，会经历两次 GC 过程。我将整个过程概括为 3 个阶段：

• 阶段 1 - 首次 GC 过程： 当垃圾收集器发现对象变成不可达对象时，会解绑实际对象与引用对象的关联关系。当实际对象被清除后，会将引用对象加入关联的引用队列（这个部分我们在上一篇文章中分析过了）。然而，finalizable 对象还需要调用 finalize() 方法，所以首次 GC 时还不能回收实际对象。为此，垃圾收集器会主动将原本不可达的实际对象重新标记为可达对象，使其从本次垃圾收集中豁免，并且将实际对象临时保存到 FinalizerReference 的 zombie 字段中。实际对象与 FinalizerReference 的关联关系依然会解除，否则会陷入死循环永远无法回收；
• 阶段 2 - FinalizerDaemon 执行 finalize() 方法： FinalizerDaemon 守护线程消费引用队列时，调用 ReferenceQueue#get() 只是返回暂存在 zombie 字段中的实际对象而已，其实此时关联关系早就解除了（这就是为什么 FinalizerReference#get() 还可以获得实际对象）。
• 阶段 3 - 二次 GC： 由于实际对象和 FinalizerReference 已经没有关联关系了，第二次回收过程跟普通对象相同。前提是 finalize() 中将实际对象重新变成可达对象，那么二次 GC 不会那么快执行，要等到它重新变为不可达状态。

提示： 这就是为什么 finalize() 方法只会执行一次，因为执行 finalize() 时实际对象和 FinalizerReference 已经解除关联了，后续的垃圾回收跟普通的非 finalizable 对象一样。

源码摘要如下：

垃圾收集器清理过程：

方法调用链： ReclaimPhase→ProcessReferences→ReferenceProcessor::ProcessReferences→ReferenceQueue::EnqueueFinalizerReferences

reference_queue.cc

void ReferenceQueue::EnqueueFinalizerReferences(ReferenceQueue* cleared_references, collector::GarbageCollector* collector) {
    while (!IsEmpty()) {
        ObjPtr<mirror::FinalizerReference> ref = DequeuePendingReference()->AsFinalizerReference();
        mirror::HeapReference<mirror::Object>* referent_addr = ref->GetReferentReferenceAddr();
        // IsNullOrMarkedHeapReference：判断引用指向的实际对象是否被标记
        if (!collector->IsNullOrMarkedHeapReference(referent_addr, /*do_atomic_update*/false)) {
            // MarkObject：重新标记位可达对象
            ObjPtr<mirror::Object> forward_address = collector->MarkObject(referent_addr->AsMirrorPtr());
            // 将实际对象暂存到 zombie 字段
            ref->SetZombie<false>(forward_address);
            // 解除关联关系（普通引用对象亦有此操作）
            ref->ClearReferent<false>();
            // 将引用对象加入 cleared_references 队列（普通引用对象亦有此操作）
            cleared_references->EnqueueReference(ref);
        }
        DisableReadBarrierForReference(ref->AsReference());
    }
}

实际对象暂存在 zombie 字段中：

FinalizerReference.java

// 由虚拟机维护，用于暂存实际对象
private T zombie;

// 2.2 取出引用所指向的对象（其实是取 zombie 字段）
@Override public T get() {
    return zombie;
}

// 2.3 解除关联关系，实际上虚拟机内部早就解除关联关系了，这里只是返回暂存在 zombie 中的实际对象
@Override public void clear() {
    zombie = null;
}

至此，Finalizer 机制实现原理分析完毕。

使用一张示意图概括整个过程：

---

3. 总结

总结一下 Finalizer 机制最主要的环节：

• 1、为了实现对象的 Finalizer 机制，虚拟机设计了 FinalizerReference 引用类型。重写了 Object#finalize() 方法的类型在类加载过程中会被标记位 finalizable 类型，每次创建对象时会同步创建关联的 FinalizerReference 引用对象；
• 2、不可达对象在即将被垃圾收集器回收时，虚拟机会解除实际对象与引用对象的关联关系，并将引用对象加入关联的引用队列中。然而，由于 finalizable 对象还需要执行 finalize() 方法，因此垃圾收集器会主动将对象标记为可达对象，并将实际对象暂存到 FinalizerReference 的 zombie 字段中；
• 3、守护线程 ReferenceQueueDaemon 会轮询全局临时队列 unenqueued 队列，将引用对象分别投递到关联的引用队列中
• 4、守护线程 FinalizerDaemon 会轮询观察引用队列，并执行实际对象上的 finalize() 方法。

---

参考资料

• Effective Java（第 3 版）（8. 避免使用 Finalizer 和 Cleanr 机制） —— [美] Joshua Bloch 著
• 深入理解 Android：Java 虚拟机 ART（第 14 章 · ART 中的 GC） —— 邓凡平 著
• 深入理解 Java 虚拟机（第 3 版）（第 3 章 · 垃圾收集器与内存分配策略） —— 周志明 著

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

不只代码。