上一篇在说Java软引用时，只是简单的得出一个结论：在内存实在不足时，会对软引用进行回收。但没有说清楚，到底什么时候会被回收。
先来看看SoftReference的实现：
public class SoftReference<T> extends Reference<T> {
//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<? super T> 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软引用终于被打爆。
