定义
SoftReference是软引用，其引用的对象在内存不足的时候会被回收。只有软引用指向的对象称为软可达（softly-reachable）对象。
说明
垃圾回收器会在内存不足，经过一次垃圾回收后，内存仍旧不足的时候回收掉软可达对象。在虚拟机抛出OOM之前，会保证已经清除了所有指向软可达对象的软引用。
如果内存足够，并没有规定回收软引用的具体时间，所以在内存充足的情况下，软引用对象也可能存活很长时间。
JVM会根据当前内存的情况来决定是否回收softly-reachable对象，但只要referent有强引用存在，该referent就一定不会被清理，因此SoftReference适合用来实现memory-sensitive caches。软引用的回收策略在不同的JVM实现会略有不同。
另外，JVM不仅仅只会考虑当前内存情况，还会考虑软引用所指向的referent最近使用情况和创建时间来综合决定是否回收该referent。
一般而言，SoftReference对象会在垃圾回收器回收其内部referent后，才会被放入其注册的引用队列中（如果创建时注册了的话）。
Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand.
就是说，软引用具体什么时候回收最终还是由虚拟机自己决定的，所以不同虚拟机对软引用的回收方式会有些不一样。
SoftReference源码
public class SoftReference<T> extends Reference<T> {
/**
* 由垃圾回收器负责更新的时间戳
*/
static private long clock;
/**
* 在get方法调用时更新的时间戳，当虚拟机选择软引用进行清理时，可能会参考这个字段。
*/
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;
}
/**
* 返回引用指向的对象，如果referent已经被程序或者垃圾回收器清理，则返回null。
*/
public T get() {
T o = super.get();
if (o != null && this.timestamp != clock)
this.timestamp = clock;
return o;
}
}
SoftReference类内部代码很少，两个成员变量，clock是一个静态变量，是由垃圾回收器负责更新的时间戳，在JVM初始化时，会对变量clock进行初始化，同时，在JVM发生GC时，也会更新clock的值，所以clock会记录上次GC发生的时间点。
timestamp是在创建和更新时更新的时间戳，将其更新为clock的值，垃圾回收器在回收软引用对象时可能会参考timestamp。
SoftReference类有两个构造函数，一个是不传引用队列，一个传引用队列。在创建时，都会更新timestamp，将其赋值为clock的值，get方法也并没有什么骚操作，只是简单的调用 super.get() 并在返回值不为null时更新timestamp。
软引用何时回收
前面说过，软引用会在内存不足的时候进行回收，但是回收时并不会一次性全部回收，而是会使用一定的回收策略。
下面以最常用的虚拟机HotSpot进行说明。下面是Oracle文档中的说明：
The default value is 1000 ms per megabyte, which means that a soft reference will survive (after the last strong reference to the object has been collected) for 1 second for each megabyte of free space in the heap
默认的生存周期为1000ms/Mb，举个具体的栗子：
假设，堆内存为512Mb，并且可用内存为400Mb，我们创建一个object A，用软引用创建一个引用A的缓存对象cache，以及另一个object B 引用object A。此时，由于B持有A的强引用，所以对象A是强可达并且不会被垃圾回收器回收。
如果B被删除了，那么A仅剩下一个软引用cache引用它，如果A在400s内没有再次被强引用关联，它将会在超时后被删除。
下面是一个控制软引用的栗子：
public class SoftRefTest {
public static class A{
}
public static class B{
private A strongRef;
public void setStrongRef(A ref) {
this.strongRef = ref;
}
}
public static SoftReference<A> cache;
public static void main(String[] args) throws InterruptedException{
//用一个A类实例的软引用初始化cache对象
SoftRefTest.A instanceA = new SoftRefTest.A();
cache = new SoftReference<SoftRefTest.A>(instanceA);
instanceA = null;
// instanceA 现在是软可达状态，并且会在之后的某个时间被垃圾回收器回收
Thread.sleep(10000);
...
SoftRefTest.B instanceB = new SoftRefTest.B();
//由于cache仅持有instanceA的软引用，所以无法保证instanceA仍然存活
instanceA = cache.get();
if (instanceA == null){
instanceA = new SoftRefTest.A();
cache = new SoftReference<SoftRefTest.A>(instanceA);
}
instanceB.setStrongRef(instanceA);
instanceA = null;
// instanceA现在与cache对象存在软引用并且与B对象存在强引用，所以它不会被垃圾回收器回收
...
}
}
但是需要注意的是，被软引用对象关联的对象会自动被垃圾回收器回收，但是软引用对象本身也是一个对象，这些创建的软引用并不会自动被垃圾回收器回收掉，所以在之前一篇中说明里的栗子里，软引用是不会被释放掉的。
所以，你仍然需要手动去清理它们，否则也会导致OOM的产生，这里也举一个小栗子：
public class SoftReferenceTest{
public static class MyBigObject{
int[] data = new int[128];
}
public static int CACHE_INITIAL_CAPACITY = 100_000;
// 静态集合保存软引用，会导致这些软引用对象本身无法被垃圾回收器回收
public static Set<SoftReference<MyBigObject>> cache = new HashSet<>(CACHE_INITIAL_CAPACITY);
public static void main(String[] args) {
for (int i = 0; i < 100_000; i++) {
MyBigObject obj = new MyBigObject();
cache.add(new SoftReference<>(obj));
if (i%10_000 == 0){
System.out.println("size of cache:" + cache.size());
}
}
System.out.println("End");
}
}
使用的虚拟机参数为：
-Xms4m -Xmx4m -Xmn2m
输出如下：
size of cache:1
size of cache:10001
size of cache:20001
size of cache:30001
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
最终抛出了OOM，但这里的原因却并不是Java heap space，而是GC overhead limit exceeded ，之所以会抛出这个错误，是由于虚拟机一直在不断回收软引用，回收进行的速度过快，占用的cpu过大（超过98%），并且每次回收掉的内存过小（小于2%），导致最终抛出了这个错误。
对于这里，合适的处理方式是注册一个引用队列，每次循环之后将引用队列中出现的软引用对象从cache中移除。
public class SoftReferenceTest{
public static int removedSoftRefs = 0;
public static class MyBigObject{
int[] data = new int[128];
}
public static int CACHE_INITIAL_CAPACITY = 100_000;
// 静态集合保存软引用，会导致这些软引用对象本身无法被垃圾回收器回收
public static Set<SoftReference<MyBigObject>> cache = new HashSet<>(CACHE_INITIAL_CAPACITY);
public static ReferenceQueue<MyBigObject> referenceQueue = new ReferenceQueue<>();
public static void main(String[] args) {
for (int i = 0; i < 100_000; i++) {
MyBigObject obj = new MyBigObject();
cache.add(new SoftReference<>(obj, referenceQueue));
clearUselessReferences();
}
System.out.println("End, removed soft references=" + removedSoftRefs);
}
public static void clearUselessReferences() {
Reference<? extends MyBigObject> ref = referenceQueue.poll();
while (ref != null) {
if (cache.remove(ref)) {
removedSoftRefs++;
}
ref = referenceQueue.poll();
}
}
}
使用同样的虚拟机配置，输出如下：
End, removed soft references=97319
HotSpot虚拟机对于软引用的处理
就HotSpot虚拟机而言，常用的回收策略是基于当前堆大小的LRU策略（LRUCurrentHeapPolicy），会使用clock的值减去timestamp，得到的差值，就是这个软引用被闲置的时间，如果闲置足够长时间，就认为是可被回收的。
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");
if(interval <= _max_interval) {
return false;
}
return true;
}
这里 timestamp_clock 即SoftReference中clock的值，即上次GC时间。java_lang_ref_SoftReference::timestamp(p)可以获取引用中timestamp的值。
那么这个足够长的时间 _max_interval是怎么计算的呢？
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之后，只剩下很少的内存可用，那么SoftReference对象便会很快进行回收。
SoftReference在一定程度上会影响垃圾回收，如果软可达对象中对应的referent多次垃圾回收仍然不满足释放条件，那么它会停留在堆的老年代，占据很大部分空间，在JVM没有抛出OutOfMemoryError前，它有可能会导致频繁的Full GC，会对性能有一定的影响。
小结
- 软引用的具体回收时间与具体虚拟机有关
- 软引用中会在创建和调用get方法的时候更新内部timestamp，提供给虚拟机回收时进行参考
- hotspot虚拟机对于软引用使用的是LRU策略，回收时会根据软引用被闲置的时间和当前内存综合进行判断