Java的强、软、弱、虚引用介绍与分析

Java引用类型

Java引用主要分为4种(其实似乎是5种):

  • Strong Reference 强引用,直接引用
  • Soft Reference 软引用,间接引用
  • Weak Reference 弱引用,间接引用
  • Phantom Reference 虚引用,几乎无引用
  • Final引用,这里不介绍

强引用

Object strongReference = new Object();

我们平常使用最多的就是强引用。按照JVM规范,在GC时通过可达性分析检测到强引用可达时,这个对象不会被回收。
但是在某些情况下,强引用的这个特性会引起OutOfMemoryError,比如一直向集合中添加元素。

软引用
软引用对象仅在内存不足时会被回收,JVM保证在抛出OutOfMemoryError之前已经将软引用对象全部清理了。

弱引用
JVM不保证弱引用对象的回收时机,在GC线程发现该对象为弱引用对象时就会回收。

虚引用
任何时候都可能会被回收。

Java提供了几种间接引用方式,有什么好处吗?是如何起作用的?我们从源码中一点一点看。

Reference和ReferenceQueue

ReferenceQueue
ReferenceQueue本质上是一个单向链表,链表的节点是Reference,并提供了同步非阻塞出队方法poll()
同时,ReferenceQueue提供了一个类似BlockingQueue的阻塞获取节点的方法remove()
在Reference类的构造方法中,可以指定一个ReferenceQueue

Reference
Java的强软弱虚四种中,软、弱、虚引用都是继承Reference抽象类。
核心的几个属性和方法:

public abstract class Reference {
    ......
    private T referent; // 代管的对象
    ......
    volatile ReferenceQueue queue;   // 关联的通知队列
    ......
    private static Reference pending = null;    // 静态的待处理链
    ......
    static boolean tryHandlePending(boolean waitForNotify) {......} // 负责检查pending链等关键操作
    ......
    public T get() { return this.referent; }    // 获取直接引用
    ......
}
 
 

Reference类相当于引用代理,正常情况下我们持有Reference对象的引用,Reference对象持有我们真正使用的对象T referent的引用。
Reference提供了几个重要的方法:

  • get() 获取代管对象(referent)的直接引用
  • isEnqueued() 检查是否还在队列中
  • tryHandlePending() 如果存在可回收的Reference,则将这个Reference插入到构造方法指定的ReferenceQueue中;否则wait()等待

其中,Reference创建了一个名为“Reference Handler”的常驻后台线程,用于将referent已被回收的Reference对象加入其引用通知队列ReferenceQueue。

Reference中的referent
Reference中的referent会受到GC的特殊对待:

  • GC检测到reference.referent(非静态)引用可达性发生变化时,会将对应的Reference对象挂在Reference.pending(静态)链上

ps.文档未介绍“可达性发生变化”是什么情况,我猜测是处于“仅Reference对象持有直接引用”的状态。这个状态按理说是不能回收的,因为引用分析是可达的,但这里特殊处理,即使可达GC也可以回收。

综合看Reference和ReferenceQueue
这两个类形成了一个回收通知机制:

  1. 新建一个Reference对象,在构造方法中为其绑定一个间接引用对象referent,及一个回收通知队列referenceQueue
  2. 去除referent的其他直接引用
  3. Reference类在应用启动时就创建了Reference Handler线程,但Reference.tryHandlePending方法发现pending对象为null,线程进入WAIT状态,pending保存的是需要回收的Reference链的首个节点
  4. GC在回收这个Reference对象的referent时,将其Reference对象挂在Reference.pending链上,即GC会将所有达到可回收状态的Reference对象挂到静态的pending链上
  5. Reference Handler线程被唤醒,通过Reference.tryHandlePending方法发现pending中有内容,将链上的Reference对象插入其构造方法指定的referenceQueue中(当然,如果没有指定那么就不会入队)
  6. 我们通过referenceQueue的remove()阻塞poll()非阻塞方法可以拿到哪些Reference对象的referent已被回收,可以进行接下来的善后处理
参考资料中的图

应用场景

  • 软引用
    官方文档提到,软引用非常适合用于内存敏感的缓存,当内存不足时GC将会回收缓存中的部分内容。
    ps.有参考资料提到软引用可能导致频繁Full GC。
  • 弱引用
    官方文档提到,弱引用适合用于规范化映射(Canonicalizing Mappings),可以理解为一个Map中的KV映射。
  • 虚引用
    PhantomReference.get()方法永远返回null,因此一旦失去直接引用仅保留虚引用,那么就无法再获取这个对象的引用。适合用于监控对象是否被回收。

一个典型的应用就是WeakHashMap类。
WeakHashMap中的Entry继承自WeakReference类,其中key就是间接引用中的referent,获取key均是通过Reference对象的get()方法,即有可能失效。
另外,WeakHashMap持有一个ReferenceQueue对象,每个Entry都在构造方法中关联了这个queue。
expungeStaleEntries()方法会清理失效的Entry,作为大多数方法的前置操作。

结合上边的回收通知机制等分析,WeakHashMap有这些特点:

  1. 使用弱引用作为Entry,referent是Entry的key,并关联了一个内部的ReferenceQueue
  2. 每次GC时都会清理掉一部分Entry的referent,key变为null——相当于这些内容在Map中“消失”了,不过value占用的空间还没清理
  3. key被清理的Entry,如前所述会进入回收通知队列ReferenceQueue
  4. 在绝大部分操作之前会先从回收通知队列中获取失效的Entry,并从Map中真正删除

回收通知机制的好处

  1. GC虽然做了特殊处理,但是插入链表这个额外的操作相对来说负担是非常小的,对GC影响不大,回收通知机制后续的逻辑其实是Reference Handler线程在做。
  2. 使用间接引用后,如何清理被回收的数据及相关数据,或者如何接收被回收通知是个问题。
    以WeakHashMap举例,被回收的数据都在ReferenceQueue中,比起遍历整个集合查看哪些数据被回收了,显然使用通知机制仅查这个queue效率要高得多。

参考资料

JDK源码阅读-Reference
Java Reference详解 - robin-yao的个人页面 - OSCHINA
Java 理论与实践: 用弱引用堵住内存泄漏

本文搬自我的博客,欢迎参观!

你可能感兴趣的:(Java的强、软、弱、虚引用介绍与分析)