提问Java四大引用？

四大引用各自回收条件？获取对象方式？触发OOM概率？

回答这个问题的最好方式就是编码验证。

本文代码运行环境：Mac os + jdk se 8 + VM options (-Xms10m -Xmx10m)

被测试对象类RefTestObj

java-ref-RefTestObj.png

RefTestObj定义了三个成员变量，重写了toString和finalize方法。

测试OOM

测试代码：使用不同引用类型循环创建10w个RefTestObj对象，测试其发生OOM概率。

java-ref-refTestOOM.png

• 强引用：调用 refTestOOM(0) ，大概在创建1.5w个对象时出现OOM，在此之前没有打印过任何finalize方法日志。
• 软引用：调用 refTestOOM(1) ，顺利创建完所有对象。 期间控制台有几次（大量对象的）finalize方法日志输出。
• 弱引用：调用tefTestOOM(2) ，顺利创建完所有对象。 期间控制台基本都在打印finalize方法日志。
• 虚引用：调用refTestOOM(3) ，大概在创建3w个对象时出现OOM，在此之前有打印过finalize方法日志。
• 细心的读者可能已经发现测试代码中124行，做了100ms延时操作。如果没有这个延时，软引用和弱引用也会出现OOM，原因请看代码注释和下一个问题。

测试结果

引用类型	回收条件	获取对象方式	触发OOM概率
强引用	不回收	通过引用	高
软引用	内存紧张时	get方法	低
弱引用	GC时	get方法	很低
虚引用	不确定？	无法获取	较高？

• StrongRef 直到OOM也不回收其引用的对象。 通过引用直接获取目标对象实例。
• SoftRef 内存吃紧时回收其引用的对象。 通过get方法获取对象引用，可能为null。 不会触发OOM(如果没时间释放内存也会触发OOM(比如创建对象太快))
• WeakRef GC时触发回收。 get方法获取对象引用，可能为null。 不会触发OOM。(如果没时间释放内存也会触发OOM(比如创建对象太快)) 。 较SoftRef 对象执行finalize更频繁，极端情况出现OOM概率也更低。
• PhantomRef 回收条件：不确定，看日志有执行finalize函数。 无法获取对象实例。 会触发OOM（较SoftRef和WeakRef概率高, 感觉和StrongRef差不多）。

为什么使用了WeakRef（SoftRef）也会触发OOM？

• 创建对象时，需要在堆中申请内存，如果申请时内存不够就会触发OOM。
• JVM根据算法在整理和释放对象(没有使用的)内存，而且这两个过程不是同步的。

对象的finalize方法什么时候被执行？ 什么时候被放入ReferenceQueue中的？

公用测试代码 referenceQueueMonitor ：用于监控ReferenceQueue中对象，如果有则取出并打印日志。

java-ref-queueMonitor.png

测试弱引用 testWeakReferenceQueue

java-ref-testWeakReferenceQueue.png

运行日志

java-ref-testWeakReferenceQueue-result.png

结果分析

• 弱引用在GC触发后就回收对象。
• GC后其指向的对象会被加入关联的ReferenceQueue，和执行对象的finalize方法。
• 关于finalize方法调用：1. 由JVM调用，时机不确定， 2. 最多只调用一次。

测试软引用 testSoftReferenceQueue

java-ref-testSoftReferenceQueue.png

运行日志

java-ref-testSoftReferenceQueue-result.png

结果分析

• 从日志可以看到，通过19次gc后软引用指向的对象终于被清理了。（每多一次gc，就会多创建1000个对象，以此来模拟内存吃紧的情况。）
• 软引用指向对象会在内存接近满负荷时，垃圾回收器将会清理该对象；可能还会根据SoftReference.get()方法的调用情况(比如很长时间未调用)来决定要不要回收。
• 从日志来看软引用在执行对象的 finalize 方法之前被加入了 ReferenceQueue；但实际上这两个是相互独立的逻辑，可参看下文 源码分析 章节。

测试虚引用 testPhantomReferenceQueue

java-ref-testPhantomReferenceQueue.png

运行日志

java-ref-testPhantomReferenceQueue-result.png

结果分析

• 虚引用在GC触发后 , 直接调用了 finalize() 方法 , 但不会立即将其加入回收队列 .
• 只有在真正对象被 GC 清除时 , 才会将其加入 ReferenceQueue 队列中去 .
• 对于虚引用对象，到底在经过多次 GC 之后， 才会加入到队列中去呢？ （经过测试，发现在二次GC后会将其加入队列；关于什么时机将对象加入队列，各个虚拟机实现应该是有差异的。）

以上只是带着问题并通过编码来验证的过程，如果想搞清楚答案为什么是这样而不是那样，就需要翻一翻jdk相关的代码了。

源码实现

对象是怎么被加入ReferenceQueue的？

在java.lang.ref.Reference类中定义有下图所示的一段静态代码。

java-ref-reference-static-code.png

由上图代码可以看出，在Reference类装载时就会启动一个名叫ReferenceHandler的高优先级的守护线程。ShareSecrets类相关逻辑先忽略，我们继续看看ReferenceHandler线程类的定义。

java-ref-reference-referenceHandler.png

重点关注run方法。可以看到一个无限循环逻辑在执行tryHandlePending(true)方法，在看tryHandlePending方法代码前，我们先看下Reference类中定义的几个变量。(因为它们很重要，也便于后续代码理解)

java-ref-reference-member-code.png

简单说下，

• 变量 referent -> 对象引用实例。
• 变量 queue -> 该引用类型关联的ReferenceQueue实例，它本身并不是一个队列结构实现。
• 变量 next -> 对象入队后用此变量来维护一个链表结构。
• 变量 discovered 和 pending 为Reference类型，均有VM调用并赋值。
• 变量 lock 同步锁对象。我理解是VM检测到有待处理对象时会通过此对象唤醒ReferenceHandler线程。

下面再来看看 tryHandlePending 方法实现。

java-ref-reference-tryHandlePending.png

方法主要逻辑：获取对象锁并判断 pending 变量是否为null？

• 为null：根据参数waitForNotify 决定是 wait 还是继续循环执行。
• 不为null：进行赋值，并判断如果不是Cleaner对象则将其放入队列中。

到这里，关于Reference对象如何被放入队列的代码逻辑就分析完了。前面我有提到说java.lang.ref.ReferenceQueue类并不是一个队列，那我们看看其 enqueue(r) 方法是如何实现的？

java-ref-referenceQueue-enqueue.png

其实它是使用自定义的一个 head 变量和Reference类的 next 变量来实现的队列效果。

这里也有lock锁对象，最后一句代码还执行了notifyAll()，原因就是该类对外提供了一个阻塞 remove 方法，调用notifyAll()可唤醒在该锁上等待的线程，具体代码就不贴了，感兴趣的读者请自行查阅。

对象的 finalize()方法执行逻辑？

在java.lang.ref.Finalizer类中定义有如下代码，可以看出FinalizerThread线程在类装载时就被启动了。

java-ref-Finalizer-FinalizerThread.png

FinalizerThread 线程主要逻辑就是从引用队列 queue 中取出Finalizer对象，并执行其 runFinalizer()方法。

注意：这里的 queue 是Finalizer类中定义的静态变量和我们创建引用对象传入的queue不是同一个哦。

继续跟进 runFinalizer方法 ~

java-ref-Finalizer-runFinalizer.png

上图中第 97 行代码 remove 方法主要是将当前Finalizer引用(对象)从链表中移除；第101 、102 行代码可看出只要其关联的 目标对象 不为null且不是枚举类型，则执行其finalize()方法；第 109 行代码调用了 super.clear() 方法将目标对象引用置为null，已防止重复执行finalize方法。

虚引用(PhantomReference) 存在的意义和使用场景是？

这个不常用，可参看其子类sun.misc.Cleaner。

参考文中测试代码？传送门~
由于水平有限，文中错误之处难免，发现问题还望指出；如果你对文中观点有不同看法请留言告诉我，谢谢。