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

用户9995743

发布于 2022-09-26 21:00:06

7890

文章被收录于专栏：彭旭锐彭旭锐

🔥 Hi，我是小彭。本文已收录到 GitHub · AndroidFamily[1] 中。

前言

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] —— 周志明著

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

参考资料

[1]

GitHub · AndroidFamily: https://github.com/pengxurui/Android-NoteBook

[2]

java_lang_ref_Reference.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/native/java_lang_ref_Reference.cc

[3]

runtime.cc: https://www.androidos.net.cn/android/9.0.0_r8/xref/art/runtime/runtime.cc

[4]

Daemons.java: https://www.androidos.net.cn/android/9.0.0_r8/xref/libcore/libart/src/main/java/java/lang/Daemons.java

[5]

mark_sweep.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/gc/collector/mark_sweep.cc

[6]

reference_processor.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/gc/reference_processor.cc#GetReferent

[7]

reference_processor.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/gc/reference_processor.cc#GetReferent

[8]

reference_queue.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/gc/reference_queue.cc

[9]

reference_processor.cc: http://androidxref.com/9.0.0_r3/xref/art/runtime/gc/reference_processor.cc#251

[10]

Effective Java（第 3 版）（8. 避免使用 Finalizer 和 Cleanr 机制）: https://www.cnblogs.com/IcanFixIt/p/8133798.html

[11]

深入理解 Android：Java 虚拟机 ART（第 14 章 · ART 中的 GC）: https://weread.qq.com/web/reader/3ee32e60717f5af83ee7b37k5b832ac0313d5b8add2af21

[12]

深入理解 Java 虚拟机（第 3 版）（第 3 章 · 垃圾收集器与内存分配策略）: https://weread.qq.com/web/reader/9b832f305933f09b86bd2a9k16732dc0161679091c5aeb1

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2022-08-23，如有侵权请联系 cloudcommunity@tencent.com 删除

c++

本文分享自彭旭锐微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度