SoftReference 到底在什么时候被回收 ？ 如何量化内存不足 ？

大家在网上或者在其他讲解 JVM 的书籍中多多少少会看到这样一段关于 SoftReference 的描述 —— “当 SoftReference 所引用的 referent 对象在整个堆中没有其他强引用的时候，发生 GC 的时候，如果此时内存充足，那么这个 referent 对象就和其他强引用一样，不会被 GC 掉，如果此时内存不足，系统即将 OOM 之前，那么这个 referent 对象就会被当做垃圾回收掉”。

当然了，如果仅从概念上理解的话，这样描述就够了，但是如果我们从 JVM 的实现角度上来说，那这样的描述至少是不准确的，为什么呢 ？ 笔者先提两个问题出来，大家可以先思考下：

1. 内存充足的情况下，SoftReference 所引用的 referent 对象就一定不会被回收吗 ？

2. 什么是内存不足 ？这个概念如何量化，SoftReference 所引用的 referent 对象到底什么时候被回收 ？

下面笔者继续以 ZGC 为例，带大家深入到 JVM 内部去探寻下这两个问题的精确答案~~

篇幅限制下面就只能给大家展示小册部分内容了。这份面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记的【点击此处即可】即可免费获取

1. JVM 无条件回收 SoftReference 的场景

经过前面第五小节的介绍，我们知道 ZGC 在 Concurrent Mark 以及 Concurrent Process Non-Strong References 阶段中处理 Reference 对象的关键逻辑都封装在 ZReferenceProcessor 中。

在 ZReferenceProcessor 中有一个关键的属性 —— _soft_reference_policy，在 ZGC 的过程中，处理 SoftReference 的策略就封装在这里，本小节开头提出的那两个问题的答案就隐藏在 _soft_reference_policy 中。

c

复制代码

class ZReferenceProcessor : public ReferenceDiscoverer { // 关于 SoftReference 的处理策略 ReferencePolicy* _soft_reference_policy; }

那下面的问题就是如果我们能够知道 _soft_reference_policy 的初始化逻辑，那是不是关于 SoftReference 的一切疑惑就迎刃而解了 ？我们来一起看下 _soft_reference_policy 的初始化过程。

在 ZGC 开始的时候，首先会创建一个 ZDriverGCScope 对象，这里主要进行一些 GC 的准备工作，比如更新 GC 的相关统计信息，设置并行 GC 线程个数，以及本小节的重点，初始化 SoftReference 的处理策略 —— _soft_reference_policy。

c

复制代码

void ZDriver::gc(const ZDriverRequest& request) { ZDriverGCScope scope(request); ..... 省略 ...... }

c

复制代码

class ZDriverGCScope : public StackObj { private: GCCause::Cause _gc_cause; public: ZDriverGCScope(const ZDriverRequest& request) : _gc_cause(request.cause()), { // Set up soft reference policy const bool clear = should_clear_soft_references(request); ZHeap::heap()->set_soft_reference_policy(clear); }

在 JVM 开始初始化 _soft_reference_policy 之前，会调用一个重要的方法 —— should_clear_soft_references，本小节的答案就在这里，该方法就是用来判断，ZGC 是否需要无条件清理