JVM 系列（6）吊打面试官：为什么 finalize() 方法

2022-08-11  本文已影响0人  彭旭锐

前言

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

学习路线图：

Untitled.png

1. 认识 Finalizer 机制

1.1 为什么要使用 Finalizer 机制？

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

1.2 Finalizer 存在的问题

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

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 个阶段：

提示： 这就是为什么 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 机制最主要的环节：

参考资料

上一篇 下一篇

猜你喜欢

热点阅读