文章目录
- 强引用Referrnce
-
- 整体架构
- 强引用（默认支持）
- 软引用
- 弱引用
- 软引用和弱引用的适用场景
- weakhashmap案例演示和解析
- 虚引用简介
-
- 引用队列
- ReferenceQueue引用队列简介
- 虚引用PhantomReference
- GCRoots和4大引用小总结
强引用Referrnce
绝大多数情况下用到的是强引用，软引用在缓存场景中出现。
整体架构
以前我们说的引用就是用到了Reference这一层。他就是强引用。他所在的包是java.lang.ref,如下图：
强引用（默认支持）
演示案例：
运行结果：
软引用
强引用：死了都不收。软引用：内存足够的情况下，我不收，内存不够的情况下，我要收。
代码演示：
此时内存是够用的，软引用不会被回收，效果如下：
为了演示效果（内存不够用时，软引用会被回收），先设置一下jvm参数，改小。
运行效果：
此时会发现，软引用就被回收了。
弱引用
弱引用：不管内存是否够用，只要触发gc，一定被回收。
代码示例：
运行结果：
会发现，内存足够的情况下，发生gc，直接杀掉弱引用对象。
软引用和弱引用的适用场景
假设有个读图片的场景，肯定要用缓存，第一次读的慢，以后就快了。但是图片比文字大，加载到内存空间里面，很容易就满了。
容易触发oom。
mybatis缓存的部分，大面积的使用了软引用。
weakhashmap案例演示和解析
查看你一下api文档，它位于util包：
官方介绍
hashtable实现了map接口，使用“弱key”，map中的entry将会被自动移除当他的key不再被正常的引用之后。对于给定的映射的key，不会像hashmap一样阻止gc对它回收。当一个key被回收之后，键值对就无效了。效果就相当于被从map中移除。
案例解释：
这里把key置空，map里面的数据没有影响。是因为底层源码在put的时候，转化为放入了Node对象（含有kv），所以打印是没有问题的。
基于上面的实验，触发gc：
运行结果如下：数据还在。这种情况下，map里面的数据是强引用，不会被回收的。
同样的方法，再测试一下弱hashmap，代码如下：
运行结果：
因为是弱引用：只要触发gc就回收，所以最后打印结果就没了。发生oom的概率会大大降低。
这种类方便我们做高速缓存和对内存敏感的业务场景。
虚引用简介
虚引用又称为幽灵引用。
类继承结构图：
引用队列
虚引用被回收之前，要被引用队列保存一下。
ReferenceQueue引用队列简介
代码示例：
运行结果：
gc之前没有，gc之后反而进了队列了。
虚引用被回收之前，要被引用队列保存一下。利用这个api，weakreference也可以。
虚引用PhantomReference
虚引用是监控一个对象的回收信息，然后回收之前把他放到referencequeue中保存一下。类似spring aop的后置通知。
看下面代码就可以明白：
打印查看回收情况：
gc之前，虚引用每次get都是null，gc之后，get还是null，但是就被放到引用队列里面了。
GCRoots和4大引用小总结