前言

在Java语言中，除了原始数据类型的变量，其余全部都是所谓的引用类型，指向各类不一样的对象，理解引用对于掌握Java对象生命周期和JVM内部相关机制很是有帮助。java

今天我要问你的问题是，强引用、软引用、弱引用、幻象引用有什么区别？具体使用场景是什么？面试

不一样的引用类型，主要体现的是对象不一样的可达性（reachable）状态和对垃圾收集的影响。缓存

强引用

就是咱们最多见的普通对象引用，只要还有强引用指向一个对象，就能代表对象还“活着”，垃圾收集器不会碰这种对象。对于一个普通的对象，若是没有其余的引用关系，只要超过了引用的做用域或者显式地将相应（强）引用赋值为null，就是能够被垃圾收集的了，固然具体回收时机仍是要看垃圾收集策略。框架

软引用

是一种相对强引用弱化一些的引用，可让对象豁免一些垃圾收集，只有当JVM认为内存不足时，才会去试图回收软引用指向的对象。JVM会确保在抛出OutOfMemoryError以前，清理软引用指向的对象。软引用一般用来实现内存敏感的缓存，若是还有空闲内存，就能够暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。异步

弱引用

并不能使对象豁免垃圾收集，仅仅是提供一种访问在弱引用状态下对象的途径。这就能够用来构建一种没有特定约束的关系，好比，维护一种非强制性的映射关系，若是试图获取时对象还在，就使用它，不然重现实例化。它一样是不少缓存实现的选择。异步编程

对于幻象引用，有时候也翻译成虚引用，你不能经过它访问对象。幻象引用仅仅是提供了一种确保对象被finalize之后，作某些事情的机制，好比，一般用来作所谓的Post-Mortem清理机制，我在专栏上一讲中介绍的Java平台自身Cleaner机制等，也有人利用幻象引用监控对象的建立和销毁。工具

考点分析

这道面试题，属于既偏门又很是高频的一道题目。说它偏门，是由于在大多数应用开发中，不多直接操做各类不一样引用，虽然咱们使用的类库、框架可能利用了其机制。它被频繁问到，是由于这是一个综合性的题目，既考察了咱们对基础概念的理解，也考察了对底层对象生命周期、垃圾收集机制等的掌握。学习

充分理解这些引用，对于咱们设计可靠的缓存等框架，或者诊断应用OOM等问题，会颇有帮助。好比，诊断MySQL connector-j驱动在特定模式下（useCompression=true）的内存泄漏问题，就须要咱们理解怎么排查幻象引用的堆积问题。this

知识扩展

1.对象可达性状态流转分析

首先，请你看下面流程图，我这里简单总结了对象生命周期和不一样可达性状态，以及不一样状态可能的改变关系，可能未必100%严谨，来阐述下可达性的变化。

我来解释一下上图的具体状态，这是Java定义的不一样可达性级别（reachability level），具体以下：

强可达（Strongly Reachable），就是当一个对象能够有一个或多个线程能够不经过各类引用访问到的状况。好比，咱们新建立一个对象，那么建立它的线程对它就是强可达。
软可达（Softly Reachable），就是当咱们只能经过软引用才能访问到对象的状态。
弱可达（Weakly Reachable），相似前面提到的，就是没法经过强引用或者软引用访问，只能经过弱引用访问时的状态。这是十分临近finalize状态的时机，当弱引用被清除的时候，就符合finalize的条件了。
幻象可达（Phantom Reachable），上面流程图已经很直观了，就是没有强、软、弱引用关联，而且finalize过了，只有幻象引用指向这个对象的时候。
固然，还有一个最后的状态，就是不可达（unreachable），意味着对象能够被清除了。

判断对象可达性，是JVM垃圾收集器决定如何处理对象的一部分考虑。

全部引用类型，都是抽象类java.lang.ref.Reference的子类，你可能注意到它提供了get()方法：

除了幻象引用（由于get永远返回null），若是对象尚未被销毁，均可以经过get方法获取原有对象。这意味着，利用软引用和弱引用，咱们能够将访问到的对象，从新指向强引用，也就是人为的改变了对象的可达性状态！这也是为何我在上面图里有些地方画了双向箭头。

因此，对于软引用、弱引用之类，垃圾收集器可能会存在二次确认的问题，以保证处于弱引用状态的对象，没有改变为强引用。

可是，你以为这里有没有可能出现什么问题呢？

不错，若是咱们错误的保持了强引用（好比，赋值给了static变量），那么对象可能就没有机会变回相似弱引用的可达性状态了，就会产生内存泄漏。因此，检查弱引用指向对象是否被垃圾收集，也是诊断是否有特定内存泄漏的一个思路，若是咱们的框架使用到弱引用又怀疑有内存泄漏，就能够从这个角度检查。

2.引用队列（ReferenceQueue）使用

谈到各类引用的编程，就必然要提到引用队列。咱们在建立各类引用并关联到相应对象时，能够选择是否须要关联引用队列，JVM会在特定时机将引用enqueue到队列里，咱们能够从队列里获取引用（remove方法在这里实际是有获取的意思）进行相关后续逻辑。尤为是幻象引用，get方法只返回null，若是再不指定引用队列，基本就没有意义了。看看下面的示例代码。利用引用队列，咱们能够在对象处于相应状态时（对于幻象引用，就是前面说的被finalize了，处于幻象可达状态），执行后期处理逻辑。

Object counter = new Object();
ReferenceQueue refQueue = new ReferenceQueue<>();
PhantomReference p = new PhantomReference<>(counter, refQueue);
counter = null;
System.gc();
try {
	// Remove是一个阻塞方法，能够指定timeout，或者选择一直阻塞 Reference ref = refQueue.remove(1000L); if (ref != null) { // do something }} catch (InterruptedException e) { // Handle it}

3.显式地影响软引用垃圾收集

前面泛泛提到了引用对垃圾收集的影响，尤为是软引用，到底JVM内部是怎么处理它的，其实并非很是明确。那么咱们能不能使用什么方法来影响软引用的垃圾收集呢？

答案是有的。软引用一般会在最后一次引用后，还能保持一段时间，默认值是根据堆剩余空间计算的（以M bytes为单位）。从Java 1.3.1开始，提供了-XX:SoftRefLRUPolicyMSPerMB参数，咱们能够以毫秒（milliseconds）为单位设置。好比，下面这个示例就是设置为3秒（3000毫秒）。

-XX:SoftRefLRUPolicyMSPerMB=3000

这个剩余空间，其实会受不一样JVM模式影响，对于Client模式，好比一般的Windows 32 bit JDK，剩余空间是计算当前堆里空闲的大小，因此更加倾向于回收；而对于server模式JVM，则是根据-Xmx指定的最大值来计算。

本质上，这个行为仍是个黑盒，取决于JVM实现，即便是上面提到的参数，在新版的JDK上也未必有效，另外Client模式的JDK已经逐步退出历史舞台。因此在咱们应用时，能够参考相似设置，但不要过于依赖它。

4.诊断JVM引用状况

若是你怀疑应用存在引用（或finalize）致使的回收问题，能够有不少工具或者选项可供选择，好比HotSpot JVM自身便提供了明确的选项（PrintReferenceGC）去获取相关信息，我指定了下面选项去使用JDK 8运行一个样例应用：

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC

这是JDK 8使用ParrallelGC收集的垃圾收集日志，各类引用数量很是清晰。

0.403: [GC (Allocation Failure) 0.871: [SoftReference, 0 refs, 0.0000393 secs]0.871: [WeakReference, 8 refs, 0.0000138 secs]0.871: [FinalReference, 4 refs, 0.0000094 secs]0.871: [PhantomReference, 0 refs, 0 refs, 0.0000085 secs]0.871: [JNI Weak Reference, 0.0000071 secs][PSYoungGen: 76272K->10720K(141824K)] 128286K->128422K(316928K), 0.4683919 secs] [Times: user=1.17 sys=0.03, real=0.47 secs]

注意：JDK 9对JVM和垃圾收集日志进行了普遍的重构，相似PrintGCTimeStamps和PrintReferenceGC已经再也不存在，我在专栏后面的垃圾收集主题里会更加系统的阐述。

5.Reachability Fence

除了我前面介绍的几种基本引用类型，咱们也能够经过底层API来达到强引用的效果，这就是所谓的设置reachability fence。

为何须要这种机制呢？考虑一下这样的场景，按照Java语言规范，若是一个对象没有指向强引用，就符合垃圾收集的标准，有些时候，对象自己并无强引用，可是也许它的部分属性还在被使用，这样就致使诡异的问题，因此咱们须要一个方法，在没有强引用状况下，通知JVM对象是在被使用的。提及来有点绕，咱们来看看Java 9中提供的案例。

class Resource {
	private static ExternalResource[] externalResourceArray = ... int myIndex;
	Resource(...) {
		myIndex = ... externalResourceArray[myIndex] = ...;
		...
	}
	protected void finalize() {
		externalResourceArray[myIndex] = null;
		...
	}
	public void action() {
		try {
			// 须要被保护的代码 int i = myIndex; Resource.update(externalResourceArray[i]); } finally { // 调用reachbilityFence，明确保障对象strongly reachable Reference.reachabilityFence(this); } } private static void update(ExternalResource ext) { ext.status = ...; }}

方法action的执行，依赖于对象的部分属性，因此被特定保护了起来。不然，若是咱们在代码中像下面这样调用，那么就可能会出现困扰，由于没有强引用指向咱们建立出来的Resource对象，JVM对它进行finalize操做是彻底合法的。

new Resource().action()

相似的书写结构，在异步编程中彷佛是很广泛的，由于异步编程中每每不会用传统的“执行->返回->使用”的结构。

在Java 9以前，实现相似功能相对比较繁琐，有的时候须要采起一些比较隐晦的小技巧。幸亏，java.lang.ref.Reference给咱们提供了新方法，它是JEP 193: Variable Handles的一部分，将Java平台底层的一些能力暴露出来：

static void reachabilityFence(Object ref)

在JDK源码中，reachabilityFence大多使用在Executors或者相似新的HTTP/2客户端代码中，大部分都是异步调用的状况。编程中，能够按照上面这个例子，将须要reachability保障的代码段利用try-finally包围起来，在finally里明确声明对象强可达。

总结

今天，我总结了Java语言提供的几种引用类型、相应可达状态以及对于JVM工做的意义，并分析了引用队列使用的一些实际状况，最后介绍了在新的编程模式下，如何利用API去保障对象不被意外回收，但愿对你有所帮助。

好将来面试官：说说强引用、软引用、弱引用、幻象引用有什么区别？

前言

强引用

软引用