Java软引用究竟什么时候被回收

占小狼 转载请注明原创出处，谢谢！

上一篇在说Java软引用时，只是简单的得出一个结论：在内存实在不足时，会对软引用进行回收。但没有说清楚，到底什么时候会被回收。

先来看看SoftReference的实现：

public class SoftReference extends Reference {

    //Timestamp clock, updated by the garbage collector
    static private long clock; 

    private long timestamp;

    public SoftReference(T referent) {
        super(referent);
        this.timestamp = clock;
    }
    
    public SoftReference(T referent, ReferenceQueue q) {
        super(referent, q);
        this.timestamp = clock;
    }

    public T get() {
        T o = super.get();
        if (o != null && this.timestamp != clock)
            this.timestamp = clock;
        return o;
    }
}

和其它引用不同的是，在软引用实现中，有两个特殊的变量：clock 和 timestamp。

在JVM初始化时，会对变量clock进行初始化，hotspot中的实现如下：

同时，在JVM发生GC时，也会更新clock的值，意味着clock会记录上次GC发生的时间点。不过，这个时间记录下来有什么用？

另一个变量timestamp，在软引用初始化时，会被初始化成clock，同时在get方法被调用时，也会更新timestamp的值。如果一个软引用对象在初始化后，长时间没有执行get方法，而且最近发生过GC，那么它的timestamp的值可能会远远小于clock，所以，这两个值又有什么用？

要理解这个，我们需要看看GC过程，对引用的处理逻辑，先来看一段HotSpot的代码，之前一直看的1.7版本，如果有出入也不要紧张。

代码中，我划出2个比较重要的地方。
1、iter.is_referent_alive() 这个判断软引用中的对象（referent）是否还活着，即还有没有被GC Roots可达，如果不可达，说明这个对象已经死了。
2、如果对象（referent）都死了，那么就要尝试对引用对象进行回收了，这里的尝试动作就是调用引用回收策略的should_clear_reference方法。

对于软引用的回收有几种策略，不过都差不多，我们看看其中一种：LRUCurrentHeapPolicy，它的should_clear_reference方法实现如下：

// The oop passed in is the SoftReference object, and not
// the object the SoftReference points to.
bool LRUCurrentHeapPolicy::should_clear_reference(oop p,
                                                  jlong timestamp_clock) {
  jlong interval = timestamp_clock - java_lang_ref_SoftReference::timestamp(p);
  assert(interval >= 0, "Sanity check");

  // The interval will be zero if the ref was accessed since the last scavenge/gc.
  if(interval <= _max_interval) {
    return false;
  }

  return true;
}

这里的timestamp_clock参数，就是SoftReference中clock变量的值，即上次GC的时间点。

java_lang_ref_SoftReference::timestamp(p)可以拿到该引用对象上次执行get方法的时间点，如果没有执行过get方法，就是初始化的时间点。

两者之差，就是这个软引用对象距离上次GC时一直没被使用的时间，如果这个时间大于_max_interval，说明这个软引用已经被废弃足够长时间了，被认为可以被回收了。

那么这个_max_interval临界值是多大，软引用被废弃多长时间可以被回收？

_max_interval的计算逻辑：

// Capture state (of-the-VM) information needed to evaluate the policy
void LRUCurrentHeapPolicy::setup() {
  _max_interval = (Universe::get_heap_free_at_last_gc() / M) * SoftRefLRUPolicyMSPerMB;
  assert(_max_interval >= 0,"Sanity check");
}

其中SoftRefLRUPolicyMSPerMB默认1000，看来这个值和上次GC之后的剩余堆空间大小有关，可用空间越大，_max_interval就越大。

如果GC之后，堆的可用空间还很大的话，SoftReference对象可以长时间的在堆中而不被回收。反之，如果GC之后，只剩下10M可用，那么SoftReference对象可被废弃的时间也是可以算出来的。

Java软引用终于被打爆。