四大引用各自回收条件？获取对象方式？触发OOM概率？
回答这个问题的最好方式就是编码验证。
本文代码运行环境：Mac os + jdk se 8 + VM options (-Xms10m -Xmx10m)
被测试对象类RefTestObj
RefTestObj定义了三个成员变量，重写了toString和finalize方法。
测试OOM
测试代码：使用不同引用类型循环创建10w个RefTestObj对象，测试其发生OOM概率。
- 强引用：调用 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中对象，如果有则取出并打印日志。
测试弱引用 testWeakReferenceQueue
运行日志
结果分析
- 弱引用在GC触发后就回收对象。
- GC后其指向的对象会被加入关联的ReferenceQueue，和执行对象的finalize方法。
- 关于finalize方法调用：1. 由JVM调用，时机不确定， 2. 最多只调用一次。
测试软引用 testSoftReferenceQueue
运行日志
结果分析
- 从日志可以看到，通过19次gc后软引用指向的对象终于被清理了。（每多一次gc，就会多创建1000个对象，以此来模拟内存吃紧的情况。）
- 软引用指向对象会在内存接近满负荷时，垃圾回收器将会清理该对象；可能还会根据SoftReference.get()方法的调用情况(比如很长时间未调用)来决定要不要回收。
- 从日志来看软引用在执行对象的 finalize 方法之前被加入了 ReferenceQueue；但实际上这两个是相互独立的逻辑，可参看下文
源码分析章节。
测试虚引用 testPhantomReferenceQueue
运行日志
结果分析
- 虚引用在GC触发后 , 直接调用了 finalize() 方法 , 但不会立即将其加入回收队列 .
- 只有在真正对象被 GC 清除时 , 才会将其加入 ReferenceQueue 队列中去 .
- 对于虚引用对象，到底在经过多次 GC 之后， 才会加入到队列中去呢？ （经过测试，发现在二次GC后会将其加入队列；关于什么时机将对象加入队列，各个虚拟机实现应该是有差异的。）
以上只是带着问题并通过编码来验证的过程，如果想搞清楚答案为什么是这样而不是那样，就需要翻一翻jdk相关的代码了。
源码实现
对象是怎么被加入ReferenceQueue的？
在java.lang.ref.Reference类中定义有下图所示的一段静态代码。
由上图代码可以看出，在Reference类装载时就会启动一个名叫ReferenceHandler的高优先级的守护线程。ShareSecrets类相关逻辑先忽略，我们继续看看ReferenceHandler线程类的定义。
重点关注run方法。可以看到一个无限循环逻辑在执行tryHandlePending(true)方法，在看tryHandlePending方法代码前，我们先看下Reference类中定义的几个变量。(因为它们很重要，也便于后续代码理解)
简单说下，
- 变量
referent-> 对象引用实例。 - 变量
queue-> 该引用类型关联的ReferenceQueue实例，它本身并不是一个队列结构实现。 - 变量
next-> 对象入队后用此变量来维护一个链表结构。 - 变量
discovered和pending为Reference类型，均有VM调用并赋值。 - 变量
lock同步锁对象。我理解是VM检测到有待处理对象时会通过此对象唤醒ReferenceHandler线程。
下面再来看看 tryHandlePending 方法实现。
方法主要逻辑：获取对象锁并判断 pending 变量是否为null？
- 为null：根据参数waitForNotify 决定是 wait 还是继续循环执行。
- 不为null：进行赋值，并判断如果不是Cleaner对象则将其放入队列中。
到这里，关于Reference对象如何被放入队列的代码逻辑就分析完了。前面我有提到说java.lang.ref.ReferenceQueue类并不是一个队列，那我们看看其 enqueue(r) 方法是如何实现的？
其实它是使用自定义的一个 head 变量和Reference类的 next 变量来实现的队列效果。
这里也有lock锁对象，最后一句代码还执行了notifyAll()，原因就是该类对外提供了一个阻塞 remove 方法，调用notifyAll()可唤醒在该锁上等待的线程，具体代码就不贴了，感兴趣的读者请自行查阅。
对象的 finalize()方法执行逻辑？
在java.lang.ref.Finalizer类中定义有如下代码，可以看出FinalizerThread线程在类装载时就被启动了。
FinalizerThread 线程主要逻辑就是从引用队列 queue 中取出Finalizer对象，并执行其 runFinalizer()方法。
注意：这里的 queue 是Finalizer类中定义的静态变量和我们创建引用对象传入的queue不是同一个哦。
继续跟进 runFinalizer方法 ~
上图中第 97 行代码 remove 方法主要是将当前Finalizer引用(对象)从链表中移除；第101 、102 行代码可看出只要其关联的 目标对象 不为null且不是枚举类型，则执行其finalize()方法；第 109 行代码调用了 super.clear() 方法将目标对象引用置为null，已防止重复执行finalize方法。
虚引用(PhantomReference) 存在的意义和使用场景是？
这个不常用，可参看其子类sun.misc.Cleaner。
参考文中测试代码？传送门~
由于水平有限，文中错误之处难免，发现问题还望指出；如果你对文中观点有不同看法请留言告诉我，谢谢。
