定义

SoftReference是软引用,其引用的对象在内存不足的时候会被回收。只有软引用指向的对象称为软可达(softly-reachable)对象。

说明

垃圾回收器会在内存不足,经过一次垃圾回收后,内存仍旧不足的时候回收掉软可达对象。在虚拟机抛出OOM之前,会保证已经清除了所有指向软可达对象的软引用。

如果内存足够,并没有规定回收软引用的具体时间,所以在内存充足的情况下,软引用对象也可能存活很长时间。

JVM会根据当前内存的情况来决定是否回收softly-reachable对象,但只要referent有强引用存在,该referent就一定不会被清理,因此SoftReference适合用来实现memory-sensitive caches。软引用的回收策略在不同的JVM实现会略有不同。

另外,JVM不仅仅只会考虑当前内存情况,还会考虑软引用所指向的referent最近使用情况和创建时间来综合决定是否回收该referent。

一般而言,SoftReference对象会在垃圾回收器回收其内部referent后,才会被放入其注册的引用队列中(如果创建时注册了的话)。

1
Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand.

就是说,软引用具体什么时候回收最终还是由虚拟机自己决定的,所以不同虚拟机对软引用的回收方式会有些不一样。

SoftReference源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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文档中的说明:

1
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是强可达并且不会被垃圾回收器回收。

soft-reference-1
soft-reference-1

如果B被删除了,那么A仅剩下一个软引用cache引用它,如果A在400s内没有再次被强引用关联,它将会在超时后被删除。

soft-reference-2
soft-reference-2

下面是一个控制软引用的栗子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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的产生,这里也举一个小栗子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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");
}
}

使用的虚拟机参数为:

1
-Xms4m -Xmx4m -Xmn2m

输出如下:

1
2
3
4
5
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中移除。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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();
}
}
}

使用同样的虚拟机配置,输出如下:

1
End, removed soft references=97319

HotSpot虚拟机对于软引用的处理

就HotSpot虚拟机而言,常用的回收策略是基于当前堆大小的LRU策略(LRUCurrentHeapPolicy),会使用clock的值减去timestamp,得到的差值,就是这个软引用被闲置的时间,如果闲置足够长时间,就认为是可被回收的。

1
2
3
4
5
6
7
8
9
10
11
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是怎么计算的呢?

1
2
3
4
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策略,回收时会根据软引用被闲置的时间和当前内存综合进行判断