关于java:JVM-系列5吊打面试官说一下-Java-的四种引用类型

33次阅读

共计 13964 个字符，预计需要花费 35 分钟才能阅读完成。

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

🔥 Hi，我是小彭。本文已收录到 GitHub · AndroidFamily 中。这里有 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

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

参考资料

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

你的点赞对我意义重大！微信搜寻公众号 [彭旭锐]，心愿大家能够一起探讨技术，找到气味相投的敌人，咱们下次见！

执着于现实，纯正于当下。

正文完
java
发表至： java
2022-08-11
 0
关于java:Docker-Spring-Boot-FastDFS-搭建一套分布式文件服务器太强了
关于java:Spring-MVC-四Context层级
关于java:解决SpringBoot-jar包中的文件读取问题
关于java:硬气起来了肝完这2340页大厂面试题我觉得自己生活可期