最近阅读了一些优秀的数据持久化框架，发现在缓存这一层大多数都运用了软引用这种对象引用类型，以前自己只是了解，但是为真正的使用过，所以一时兴起打算实验一把，然后分享给大家。

        java中对象引用类型分为四种，强引用、软引用、弱引用、虚引用（幽灵引用）。具体这四种不同类型的引用有什么作用，有什么不同点，有哪些应用场景，下面我将用活泼（略带逗比）的语言为各位讲解一下。

                                           强引用

        一句话形容强引用就是：“剪不断，理还乱”，经常有人稍不注意各个变量的引用关系就会导致最常见的OOM。这种引用是我们平常使用最多的一种引用类型，例如Object obj = new Object()，只要强引用还存在，垃圾收集器就不会回收掉被引用的对象。 通俗点就是变量和对象他们两个是一对坚定地情侣，不管是什么情况都不会分开，即便是他们生活的世界（jvm）毁灭了（OOM）也不会。

为了更好的体现效果加上如下jvm参数

-XX:+PrintGCDateStamps        打印GC日志的时候打印时间戳（有无都行，我习惯加上）

 -XX:+PrintGCDetails                发生GC时打印GC详细日志

 -Xmx10m -Xms10m -Xmn5m  设置jvm堆内存大小（尽量小一点，这样容易触发场景）

话不多说，来看demo：

        上面一段代码我定义了一个Object数组，每个元素引用一个UserInfo对象（所谓的强引用），在运行程序后从打印的GC日志中可以看出，当JVM内存吃紧时发生了频繁的Full GC，这个时候JVM是多么的想要把数据元素和UserInfo对象之间的关系剪断然后回收掉它，可是办不到啊！当JVM感觉无力回的时候最终还是抛出了那个藏在内心很久的OOM，轰轰烈烈的死去。GC日志实在太多裁剪主要部分如下：

                                            软引用

        软引用是此篇文章的重点，之所以会写这篇文章也是因为它，一句话形容软引用就是：“可有可无”，是用来形容变量和对象之间一种奇妙的关系，这种关系是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生OOM异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出OOM异常。测试代码如下：

        上面一段代码中我首先构建了一个大的Object数组，里面保存了一些数据，然后开始构建这个数组的软引用，主动触发一次gc，通过软引用去获取Object数组和获取当前堆中剩余可分配内存，还有配合软引用的ReferenceQueue队列中的数据。此次模拟的情况在构建byte[]之前可用内存小于3M的情况下，所以想要构建byte[]必须要进行gc，清理掉软引用引用的对象，释放空间，避免OOM的悲剧。运行结果如下：

        从上面的运行结果可以看出，正如我们预想的那样，在内存足够的时候软引用指向的对象并不会被回收掉，当有新的对象申请内存空间，剩余内存不够时，才会回收掉软引用指向的对象。

                                            弱引用

        弱引用也是此篇文章的重点，之所以会写这篇文章还因为它，一句话形容弱引用就是：“朝生夕灭”。弱引用用来描述那些生命周期只是在被创建和gc之间的对象。被弱引用关联着的对象就像是一个人，不管这个世界（JVM）是否安好，总还是要死去的。被软引用关联的对象也想唱一句：“向JVM再借五百年”。可以命运如此，不像被强引用关联的对象从出生就注定是千年的WB，万年的G，不受轮回（gc）的约束。扯得有点远，来看下面的demo：

上面的代码写的非常简单，也非常的清楚，我就不在废话介绍了，直接看结果：

        结果也非常的明显，正如我们预期的那样。经过一次轮回（gc），被弱引用关联的对象长辞了。在这里我顺便介绍一下WeakHashMap，他是弱引用的一种具体应用案例，它可以像正常HashMap那样使用，但是却不必担心像HashMap那样会引起OOM。（此处我还有一个疑问，为什么没有提供SoftHashMap呢？此处记录一下，以后具体研究）。看下面一段代码：

        即使是用上面的方法考验WeakHashMap，依然没有丝毫问题，是不是感觉有些神奇和惊喜，让我们带着惊喜可看下WeakHashMap的源码，主要代码如下：

        看见上面的两段代码，我心中的疑惑解开了一大半，如果你们看到这里不太了解HashMap的源码可以先看下我的另一篇文章《浅谈HashMap日常使用优化及源码分析》。我们可以看出WeakHashMap里面保存的数据也是数组+单向链表，只不过它的key是弱引用，但是就算是key是弱引用，gc的时候它关联的对象被回收，链表的节点数据还是在的，那为什么不会OOM呢，请看下面的代码：

        上面两张图是一段代码，由于字体比较小截图不太清晰，所以截成两张。从上面的代码可以看出expungeStaleEntries()方法的作用是检查弱引用队列里面是否有数据，如果有就代表有一些和弱引用对象相关联的对象被回收掉了。所以我们可以通过弱引用队列里面的数据知道哪些对象被回收掉了。首先去弱引用队列里面拿到被回收掉的对象的软引用，indexFor(e.hash, table.length)方法是通过软引用获取链表节点数据里面的hash值和WeakHashMap的主干数据结构数组长度计算出此链表的头结点所在数组下标。然后通过下标在数组中取得该链表头结点，依次向下遍历，如果被回收掉的是头结点数据那么该数组下标的值被设置为该节点的子节点，不是的话直到遍历到被回收的节点，把该节点的父节点直接指向该节点的子节点。在WeakHashMap的主要方法中都有调用expungeStaleEntries()方法，到此终于揭开不会OOM的原因。

                                            虚引用

        虚引用我就不过多的介绍了，平常应用比较少，而且也不推荐大家使用。虚引用和别的引用使用上区别在于必须要配合引用队列来使用，它的get()方法里就一条语句 return null；所以说不管什么情况，通过虚引用你也拿不到它指向的对象，那它有什么用处呢？ 很简单，和其他的引用一样，虚引用关联的对象被回收后，该虚引用会被放到引用队列中去，通过观察引用队列中的数据变化就可以知道哪些对象被回收掉了，达到监控对象回收情况的作用，并且当你得知某些对象已经被回收之后，你可以通过显式的回收和它相关的一些资源。但是我还是不推荐大家使用。在一些特殊的场景下这是一种优化，不过使用的时候稍有不慎就会造成相关资源的空指针。同样我也不建议大家重写finalize()方法，因为可能一个错误的逻辑会导致本来要被回收的资源结果变成了千年的WB，万年的G，永永远远的驻留在你的JVM里面了。珍爱生命，请认真对待上面两条建议。