在
使用 Memory Analyzer tool(MAT)分析内存泄漏（一）（以下简称前文）中说到：“Soft Ref(软引用)对应软可达性，只要有足够的内存，就一直保持对象，直到发现内存吃紧且没有Strong Ref时才回收对象。一般可用来实现缓存，通过java.lang.ref.SoftReference类实现。”
由于照本宣科，所以我一厢情愿的认为只要Strong Ref不可达，那么GC会自动回收Soft Ref可达的对象。正好最近项目上遇到一个旧版本DWR引起的内存泄漏（新版已修正），由于不愿更新到DWR的最新版本，所以想用Soft Ref来实现。可惜，到最后还是失败了，原因在于没正确使用Soft Ref，那么如何正确使用，在这里聊聊。
由于前文中有提到Weak Ref有个java.util.WeakHashMap实现类，所以就从它的源代码入手吧。WeakHashMap内部是一个Entry[]，而Entry是继承了WeakReference并实现Map.Entry接口的静态类，类声明：private static class Entry<K,V> extends WeakReference<K> implements Map.Entry<K,V>。好了，由此可知，Entry实际上是WeakReference的子类，每次实例化Entry也就是在实例化WeakReference，在构造函数中调用super(key, queue)为WeakReference传递标识(key)和ReferenceQueue实例(queue)。ReferenceQueue和WeakReference是联合使用的，作用是当WeakReference所引用的对象被回收后，可以通过WeakReference的poll()来得到WeakReference，但是请注意，如果再对得到的WeakReference进行get()，结果将是null，因为被Weak Ref的对象本身已经被回收。接着再看WeakHashMap的put(K key, V value)方法，该方法又关联调用了私有方法expungeStaleEntries()，expungeStaleEntries()的注释表明，该方法是用来删除失效Entry的，这里调用了ReferenceQueue的poll()方法来找出被回收的对象（已被Weak Ref），然后清除，并缩小键-值映射关系的数目。根据观察，例如remove(Object key)、size()、get(Object key)这些经常使用的方法，内部都优先调用了expungeStaleEntries()。由此可以见，在程序运行中很可能会引起被Weak Ref的对象的回收，所以每次操作都要进行WeakReference的poll()，而后续的清除工作还得手工编码完成。
好，有了WeakHashMap的实现经验，开始实现自己的SoftReference吧。
Pilot类。
/**
* Pilot class
* @author rosen jiang
*/
package org.rosenjiang.bo;
public class Pilot{
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
SoftRefedPilot类，模拟WeakHashMap的Entry。
/**
* SoftRefedPilot class
* @author rosen jiang
*/
package org.rosenjiang.bo;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
public class SoftRefedPilot extends SoftReference<Pilot> {
public int key;
public SoftRefedPilot(int key, Pilot referent, ReferenceQueue<Pilot> q) {
super(referent, q);
this.key = key;
}
}
测试类TestSoftReference。
/**
* TestSoftReference class
* @author rosen jiang
*/
package org.rosenjiang.test;
import java.lang.ref.ReferenceQueue;
import java.util.HashMap;
import java.util.Map;
import org.rosenjiang.bo.Pilot;
import org.rosenjiang.bo.SoftRefedPilot;
public class TestSoftReference {
public static void main(String[] args) {
soft();
}
static void soft(){
Map<Integer, SoftRefedPilot> map = new HashMap<Integer, SoftRefedPilot>();
ReferenceQueue<Pilot> queue = new ReferenceQueue<Pilot>();
int i = 0;
while (i < 10000000) {
Pilot p = new Pilot();
map.put(i, new SoftRefedPilot(i, p, queue));
//p = null;
SoftRefedPilot pollref = (SoftRefedPilot) queue.poll();
if (pollref != null) {//找出被软引用回收的对象
//以key为标志，从map中移除
map.remove(pollref.key);
}
i++;
}
System.out.println("done");
}
}
好了，在JVM上加入-XX:+PrintGC参数观察GC信息吧。
[GC 55120K->54791K(65088K), 0.0307371 secs]
[GC 58887K->58558K(65088K), 0.0313663 secs]
[Full GC 62654K->52534K(65088K), 0.3171671 secs]
[GC 56630K->56301K(65088K), 0.0278301 secs]
[GC 60397K->60068K(65088K), 0.0303315 secs]
[Full GC 64164K->55894K(65088K), 0.3330122 secs]
[GC 59990K->59660K(65088K), 0.0273494 secs]
[Full GC 63756K->63179K(65088K), 0.3415388 secs]
[Full GC 64640K->43968K(65088K), 0.3204639 secs]
[GC 48064K->47735K(65088K), 0.0329379 secs]
可以看到，当heap达到64m，随即被Full GC，正如前文中说到的那样，内存吃紧的时候，Soft Ref开始进行清理，另外从主观感受和客观日志表明，在Full GC的时候，的确比一般的GC要慢得多，貌似有10倍的差距。所以，利用Soft Ref来做缓存，这个效率还得重新考虑。
请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：
http://www.blogjava.net/rosen