在 jdk 1.2 及其以后，引入了强引用、软引用、弱引用、虚引用这四个概念。网上很多关于这四个概念的解释，但大多是概念性的泛泛而谈，今天我结合着代码分析了一下，首先我们先来看定义与大概解释（引用类型在包 java.lang.ref 里）。
1、强引用（StrongReference）
强引用不会被GC回收，并且在java.lang.ref里也没有实际的对应类型。举个例子来说：
Object obj = new Object();
这里的obj引用便是一个强引用，不会被GC回收。
2、软引用（SoftReference）
不可达的软引用在JVM报告内存不足的时候才会被GC回收，否则不会回收，正是由于这种特性软引用在caching和pooling 中用处广泛。软引用的用法：
1
2
3
4Object obj = new Object();
SoftReference<Object> softRef = new SoftReference(obj);
// 使用 softRef.get() 获取软引用所引用的对象
Object objg = softRef.get();
3、弱引用（WeakReference）
当GC一但发现了不可达的弱引用对象，将会释放WeakReference所引用的对象。弱引用使用方法与软引用类似，但回收策略不同。
4、虚引用（PhantomReference）
当GC一但发现了不可达的虚引用对象，将会将PhantomReference对象插入ReferenceQueue队列，而此时PhantomReference所指向的对象并没有被GC回收，而是要等到ReferenceQueue被你真正的处理后才会被回收。虚引用的用法：
1
2
3
4
5
6
7
8
9 Object obj = new Object();
ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>();
PhantomReference<Object> phanRef = new PhantomReference<Object>(obj, refQueue);
// 调用phanRef.get()不管在什么情况下会一直返回null
Object objg = phanRef.get();
// 如果obj被置为null，当GC发现了虚引用，GC会将phanRef插入进我们之前创建时传入的refQueue队列
// 注意，此时phanRef所引用的obj对象，并没有被GC回收，在我们显式地调用refQueue.poll返回phanRef之后
// 当GC第二次发现虚引用，而此时JVM将phanRef插入到refQueue会插入失败，此时GC才会对obj进行回收
Reference<? extends Object> phanRefP = refQueue.poll();
看了简单的定义之后，我们结合着代码来测试一下，强引用就不用说了，软引用的描述也很清楚，关键是 “弱引用” 与 “虚引用”。
弱引用：
1 | public static void main(String[] args) throws InterruptedException { |
由于System.gc()是告诉JVM这是一个执行GC的好时机，但具体执不执行由JVM决定，因此当JVM决定执行GC，得到的结果便是（事实上这段代码一般都会执行GC）：
1 | --begin-- |
从执行结果得知，通过调用weakRef.get()我们得到了obj对象，由于没有执行GC,因此refQueue.poll()返回的null，当我们把obj = null;此时没有引用指向堆中的obj对象了，这里JVM执行了一次GC，我们通过weakRef.get()发现返回了null，而refQueue.poll()返回了WeakReference对象，因此JVM在对obj进行了回收之后，才将weakRef插入到refQueue队列中。
虚引用：
1 | public static void main(String[] args) throws InterruptedException { |
同样，当JVM执行了GC，得到的结果便是：1
2
3
4
5
6
7
8
9
10--begin--
null
null
sleep...
wake
null
java.lang.ref.PhantomReference@44b471fe
sleep...
wake
--end--
从执行结果得知，我们先前说的没有错，phanRef.get()不管在什么情况下，都会返回null，而当JVM执行GC发现虚引用之后，JVM并没有回收obj，而是将PhantomReference对象插入到对应的虚引用队列refQueue中，当调用refQueue.poll()返回PhantomReference对象时，poll方法会先把PhantomReference的持有队列queue（ReferenceQueue<? super T>）置为NULL，NULL对象继承自ReferenceQueue，将enqueue(Reference paramReference)方法覆盖为return false，而此时obj再次被GC发现时，JVM再将PhantomReference插入到NULL队列中便会插入失败返回false，此时GC便会回收obj。事实上通过这段代码我们也的却看不出来obj是否被回收，但通过 PhantomReference 的javadoc注释中有一句是这样写的：
Once the garbage collector decides that an object obj is phantom-reachable, it is being enqueued on the corresponding queue, but its referent is not cleared. That is, the reference queue of the phantom reference must explicitly be processed by some application code.
翻译一下（这句话很简单，我相信很多人应该也看得懂）：
一旦GC决定一个“obj”是虚可达的，它（指PhantomReference）将会被入队到对应的队列，但是它的指代并没有被清除。也就是说，虚引用的引用队列一定要明确地被一些应用程序代码所处理。
弱引用与虚引用的用处
软引用很明显可以用来制作caching和pooling，而弱引用与虚引用呢？其实用处也很大，首先我们来看看弱引用，举个例子：
1
2
3
4
5
6
7class Registry {
private Set registeredObjects = new HashSet();
public void register(Object object) {
registeredObjects.add( object );
}
}
所有我添加进 registeredObjects 中的object永远不会被GC回收，因为这里有个强引用保存在registeredObjects里，另一方面如果我把代码改为如下：1
2
3
4
5
6
7class Registry {
private Set registeredObjects = new HashSet();
public void register(Object object) {
registeredObjects.add( new WeakReference(object) );
}
}
现在如果GC想要回收registeredObjects中的object，便能够实现了，同样在使用HashMap如果想实现如上的效果，一种更好的实现是使用WeakHashMap。
而虚引用呢？我们先来看看javadoc的部分说明：
Phantom references are useful for implementing cleanup operations that are necessary before an object gets garbage-collected. They are sometimes more flexible than the finalize() method.
翻译一下：
虚引用在实现一个对象被回收之前必须做清理操作是很有用的。有时候，他们比finalize()方法更灵活。
很明显的，虚引用可以用来做对象被回收之前的清理工作。
附内存泄漏管理神话类WeakHashMap：
WeakHashMap: 以弱键 实现的基于哈希表的 Map。在 WeakHashMap 中，当某个键不再正常使用时，将自动移除其条目。更精确地说，对于一个给定的键，其映射的存在并不阻止垃圾回收器对该键的丢弃，这就使该键成为可终止的，被终止，然后被回收。丢弃某个键时，其条目从映射中有效地移除.
It means that once you lose the last strong reference to an object that is working as a key in a WeakHashMap, the garbage collector will soon reclaim that map entry.
部分重要代码：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
private final ReferenceQueue<Object> queue = new ReferenceQueue<>();
private void expungeStaleEntries() {
for (Object x; (x = queue.poll()) != null; ) {
synchronized (queue) {
("unchecked")
Entry<K,V> e = (Entry<K,V>) x;
int i = indexFor(e.hash, table.length);
Entry<K,V> prev = table[i];
Entry<K,V> p = prev;
while (p != null) {
Entry<K,V> next = p.next;
if (p == e) {
if (prev == e)
table[i] = next;
else
prev.next = next;
// Must not null out e.next;
// stale entries may be in use by a HashIterator
e.value = null; // Help GC
size--;
break;
}
prev = p;
p = next;
}
}
}
}
private Entry<K,V>[] getTable() {
expungeStaleEntries();
return table;
}
public int size() {
if (size == 0)
return 0;
expungeStaleEntries();
return size;
}
private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> {
V value;
final int hash;
Entry<K,V> next;
Entry(Object key, V value,
ReferenceQueue<Object> queue,
int hash, Entry<K,V> next) {
//key value作为应用的
super(key, queue);
this.value = value;
this.hash = hash;
this.next = next;
}
}
附Reference部分源码：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
volatile ReferenceQueue<? super T> queue;
/* List of References waiting to be enqueued. The collector adds
* References to this list, while the Reference-handler thread removes
* them. This list is protected by the above lock object. The
* list uses the discovered field to link its elements.
*/
private static Reference<Object> pending = null;
/* High-priority thread to enqueue pending References
*/
private static class ReferenceHandler extends Thread {
private static void ensureClassInitialized(Class<?> clazz) {
try {
Class.forName(clazz.getName(), true, clazz.getClassLoader());
} catch (ClassNotFoundException e) {
throw (Error) new NoClassDefFoundError(e.getMessage()).initCause(e);
}
}
static {
// pre-load and initialize InterruptedException and Cleaner classes
// so that we don't get into trouble later in the run loop if there's
// memory shortage while loading/initializing them lazily.
ensureClassInitialized(InterruptedException.class);
ensureClassInitialized(Cleaner.class);
}
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
while (true) {
tryHandlePending(true);
}
}
}
/**
* Try handle pending {@link Reference} if there is one.<p>
* Return {@code true} as a hint that there might be another
* {@link Reference} pending or {@code false} when there are no more pending
* {@link Reference}s at the moment and the program can do some other
* useful work instead of looping.
*
* @param waitForNotify if {@code true} and there was no pending
* {@link Reference}, wait until notified from VM
* or interrupted; if {@code false}, return immediately
* when there is no pending {@link Reference}.
* @return {@code true} if there was a {@link Reference} pending and it
* was processed, or we waited for notification and either got it
* or thread was interrupted before being notified;
* {@code false} otherwise.
*/
static boolean tryHandlePending(boolean waitForNotify) {
Reference<Object> r;
Cleaner c;
try {
synchronized (lock) {
if (pending != null) {
r = pending;
// 'instanceof' might throw OutOfMemoryError sometimes
// so do this before un-linking 'r' from the 'pending' chain...
c = r instanceof Cleaner ? (Cleaner) r : null;
// unlink 'r' from 'pending' chain
pending = r.discovered;
r.discovered = null;
} else {
// The waiting on the lock may cause an OutOfMemoryError
// because it may try to allocate exception objects.
if (waitForNotify) {
lock.wait();
}
// retry if waited
return waitForNotify;
}
}
} catch (OutOfMemoryError x) {
// Give other threads CPU time so they hopefully drop some live references
// and GC reclaims some space.
// Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above
// persistently throws OOME for some time...
Thread.yield();
// retry
return true;
} catch (InterruptedException x) {
// retry
return true;
}
// Fast path for cleaners
if (c != null) {
c.clean();
return true;
}
ReferenceQueue<? super Object> q = r.queue;
if (q != ReferenceQueue.NULL) q.enqueue(r);
return true;
}
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() {
public boolean tryHandlePendingReference() {
return tryHandlePending(false);
}
});
}