大部分情况下我们看到是强引用,比如下面这一行:
String str1 = new String("abc");
变量str1被用来存放一个string对象的强引用上。强引用在你正在使用时这个对象时,一般是不会被垃圾回收器回收的。当出现内存空间不足时,虚拟机不会释放强引用的对象占用的空间,而是选择抛出异常(OOM)。
什么时候会回收强引用的空间呢,就是没有引用的时候,比如你这样写:
str1 = null
GC在适当的时候就会回收str1指向的空间。
而弱引用(Weak Reference)的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的时,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。
java中使用弱引用的语法是:
String str1 = new String("abc");
WeakReference<String> weakReference = new WeakReference<>(str1);
我们先来通过一个案例,看下gc对于弱引用的回收策略。
public class App {
public static WeakReference<String> weakReference1;
public static void main(String[] args) {
test1();
//test1外部,hello对象作用域结束,没有强引用指向"value"了。只有一个弱引用指向"value"
System.out.println("未进行gc时,只有弱引用指向value内存区域:" + weakReference1.get());
//此时gc时会回收弱引用
System.gc();
//此时输出都为nuill
System.out.println("进行gc时,只有弱引用指向value内存区域:" + weakReference1.get());
}
public static void test1() {
//hello对象强引用"value"
String hello = new String("value");
//weakReference1对象弱引用指向"value"
weakReference1 = new WeakReference<>(hello);
//在test1内部调用gc,此时gc不会回收弱引用,因为hello对象强引用"value"
System.gc();
System.out.println("进行gc时,强引用与弱引用同时指向value内存区域:" + weakReference1.get());
}
}
运行的结果:
进行gc时,强引用与弱引用同时指向value内存区域:value
未进行gc时,只有弱引用指向value内存区域:value
进行gc时,只有弱引用指向value内存区域:null
这里有个前置知识说下,当要获得WeakReference的object时, 首先需要判断它是否已经被GC回收,若被收回,则下列返回值为空:
weakReference1.get();
根据这个结果,我们可以得出这样的结论:
我们接着从源码层面看下弱引用。首先引入一个概念叫gc的可达性。因为本篇文章并不是专门讲gc的,所以我这里并不打算展开太多这部分,知识一句话概括下gc可达性的概念。
GC决定一个对象是否可被回收,其基本思路是从GC Root开始向下搜索,如果对象与GC Root之间存在引用链,则对象是可达的,GC会根据是否可到达与可到达性决定对象是否可以被回收。
public class WeakReference<T> extends Reference<T> {
/**
* Creates a new weak reference that refers to the given object. The new
* reference is not registered with any queue.
*
* @param referent object the new weak reference will refer to
*/
public WeakReference(T referent) {
super(referent);
}
/**
* Creates a new weak reference that refers to the given object and is
* registered with the given queue.
*
* @param referent object the new weak reference will refer to
* @param q the queue with which the reference is to be registered,
* or <tt>null</tt> if registration is not required
*/
public WeakReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q);
}
}
WeakReference
源码很简单,所以大部分逻辑都在父类Reference
中。Reference类中有个核心的类是ReferenceQueue
,这类的注释是这样写的:
Reference queues, to which registered reference objects are appended by the garbage collector after the appropriate reachability changes are detected.
翻译过来大概意思是,在检测到对象的可达性发生改变后,垃圾回收器就将已注册的引用对象添加到Reference queues队列中。
这个类有三个public方法,enqueue,poll和remove。标准的队列操作,这个很简单不展开。
然后再回到Reference类,它是这样定义的:
/**
* Abstract base class for reference objects. This class defines the
* operations common to all reference objects. Because reference objects are
* implemented in close cooperation with the garbage collector, this class may
* not be subclassed directly.
*
* @author Mark Reinhold
* @since 1.2
*/
public abstract class Reference<T> {
首先它是一个抽象类,意味着你不能直接创建此类的实例。注释的意思是,这是引用对象的抽象基类,这个类定义了引用对象的常用操作。引用对象的实现一般都和垃圾回收器密切相关。
这里有个很重要的信息就是这个类和垃圾回收密切相关。
一个reference的实例有四种状态,
Active
这是一个受会受到GC的特别关注的状态,当GC察觉到引用的可达性变化为“合适”的状态之后,reference实例的状态将变化为Pending或Inactive,到底转化为Pending状态还是Inactive状态取决于此Reference对象创建时是否注册了queue.如果注册了queue,则将添加此实例到pending-Reference list中。而新创建的Reference实例的状态是Active。
Pending
在pending-Reference list中等待着被Reference-handler 线程入队列queue中的元素处于pending状态。没有注册queue的实例是永远不可能到达这一状态。
Enqueued
当实例创建的时候加入了队列后的状态。当实例被从ReferenceQueue中移除时,它的状态变为Inactive。没有注册ReferenceQueue的不可能到达这一状态的。
Inactive
终态。一旦一个实例变为Inactive,则这个状态永远都不会再被改变了。
掌握了这四个状态,继续往下看源码,
volatile ReferenceQueue<? super T> queue;
这个queue是通过构造函数传入的,表示创建一个Reference实例时,要将其注册到那个queue上。
然后继续看有个很重要的类,
private static class ReferenceHandler extends Thread {
...
static {
ThreadGroup tg = Thread.currentThread().getThreadGroup();
for (ThreadGroup tgn = tg;
tgn != null;
tg = tgn, tgn = tg.getParent());
Thread handler = new ReferenceHandler(tg, "Reference Handler");
/* If there were a special system-only priority greater than
* MAX_PRIORITY, it would be used here
*/
handler.setPriority(Thread.MAX_PRIORITY);
handler.setDaemon(true);
handler.start();
// provide access in SharedSecrets
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
return tryHandlePending(false);
}
});
}
...
根据代码,我们知道这个线程处理类具有最高的优先级,并且是daemon状态在跑。这个线程的逻辑就是:不断的从Reference构成的pending链表上获取Reference对象,如果pending不为null,则将pending的对象进行clean,如果注册的时候有queue就进行enqueue,否则线程进行wait状态。
基于以上分析,我们可以总结下Reference的机制:
pending是由JVM来赋值的,当Reference内部的referent对象的可达状态发生改变时,JVM会将Reference对象放入到pending链表中。然后启动一个ReferenceHandler线程来处理,处理的逻辑就是调用Cleaner#clean,然后根据注册时候是否有队列决定是否调用ReferenceQueue#enqueue方法进行处理。
弱引用一般用在什么场合呢?我们可以通过一些常见的组件的源码来分析下。来看看常见的threadlocal
的源码关于弱引用的使用。
threadLocal是一个线程本地变量,每个线程维护自己的变量副本,它的实现原理简单来讲就是每个线程Thread类都有个属性ThreadLocalMap,Map是自定义实现的Entry[]数组结构,所以可以维护该线程的多个ThreadLocal变量。
图中的虚线,表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作为 Key的。
既然说是Entry,必然有key和value。其中Key即是ThreadLocal变量本身,Value则是具体该线程中的变量真实的副本值。代码如下:
static class ThreadLocalMap {
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
然后你会注意到,Entry的Key即ThreadLocal对象是采用弱引用引入的。为什么ThreadLocalMap使用弱引用存储ThreadLocal呢?
还是看上面那张图。
ThreadLocalMap使用ThreadLocal的弱引用作为key,如果一个ThreadLocal没有外部强引用来引用它,那么系统 GC 的时候,这个ThreadLocal会被回收,这样一来,ThreadLocalMap中就会出现key为null的Entry,就没有办法访问这些key为null的Entry的value,如果当前线程迟迟不结束的话(因为大部分时候我们用的都是线程池,核心线程都是长期驻留的),这些key为null的Entry的value就会一直存在一条强引用链:
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value
永远无法回收,造成内存泄漏。这样看,似乎是弱引用导致了内存泄漏?
事实上是,无论这里使用强引用还是弱引用,都有可能造成内存泄漏。如果key 使用强引用:引用的ThreadLocal的对象如果置为null,被回收了,但是ThreadLocalMap还持有ThreadLocal的强引用,如果没有手动删除,ThreadLocal不会被回收,导致Entry内存泄漏。
反过来,如果key使用了弱引用,当jvm发现内存不足时,会自动回收弱引用指向的实例内存,也就是回收对ThreadLocal对象。但是这个时候value还是存在的。不过没有关系,看源码你会发行在调用get或者set操作的时候,都有机会执行回收无效entry的操作。