使用SoftReference软引用

在使用 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