源码随想 String -> SoftReference
源码随想 String -> SoftReference
2021年7月27日 15:38:14
今天实习时看 String的源码，发现其中的一个构造方法
public String(byte bytes[], int offset, int length, String charsetName)
throws UnsupportedEncodingException {
if (charsetName == null)
throw new NullPointerException("charsetName");
checkBounds(bytes, offset, length);
this.value = StringCoding.decode(charsetName, bytes, offset, length);
}
在 StringCoding.decode()方法处点入之后，发现其实现如下：
static char[] decode(String charsetName, byte[] ba, int off, int len)
throws UnsupportedEncodingException
{
StringDecoder sd = deref(decoder);
String csn = (charsetName == null) ? "ISO-8859-1" : charsetName;
if ((sd == null) || !(csn.equals(sd.requestedCharsetName())
|| csn.equals(sd.charsetName()))) {
sd = null;
try {
Charset cs = lookupCharset(csn);
if (cs != null)
sd = new StringDecoder(cs, csn);
} catch (IllegalCharsetNameException x) {}
if (sd == null)
throw new UnsupportedEncodingException(csn);
set(decoder, sd);
}
return sd.decode(ba, off, len);
}
在 deref()方法处点入，发现其实现如下：
private static <t> T deref(ThreadLocal<softreference<t>> tl) {
SoftReference<t> sr = tl.get();
if (sr == null)
return null;
return sr.get();
}
没想到，这个 decoder居然是一个存放在 ThreadLocal里的 软引用！！！
关于 tl.get()，也就是 ThreadLocal :: get()，虽然还没看过这部分代码，但是在马士兵的课上和一些面经上面都强调过它的重要性，在这里一看到，忽然有一种他乡遇故知的感受。
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
不止如此，在 sr.get()方法中，有两个很奇怪的量 clock和 timestamp
public T get() {
T o = super.get();
if (o != null && this.timestamp != clock)
this.timestamp = clock;
return o;
}
进入到 SoftReference.java类中之后，有如下定义：
/**
* Timestamp clock, updated by the garbage collector
*/
static private long clock;
/**
* Timestamp updated by each invocation of the get method. The VM may use
* this field when selecting soft references to be cleared, but it is not
* required to do so.
*/
private long timestamp;
也就是说，clock会在每次进行垃圾收集的时候更新；timestamp会在每次方法调用的时候更新。JVM通过对 timestamp字段的监测来判断是否需要清楚弱引用。
那么到底什么时候真正进行软引用的清理呢？
首先，软引用中有一个全局变量 clock，在每一次垃圾回收的时候，它的值都会更新(in millis)。
同时，每一个软引用都有一个 timestamp变量，当前软引用每次被访问的时候都会更新(包括 初始化 和 调用get()方法)
当一次新的垃圾回收开始时，是否要回收一个软饮用对象依据如下：
timestamp的年龄多大了- 剩下的堆空间还有多少
具体的计算方式如下：
free_heap为堆中的空余空间大小（以 MB为单位）interval是上一次 GC和 现在timestamp的时间差，ms_per_mb是一个常量，保持堆中空余的每MB空间中的 软引用 的毫秒值
interval <= free_heap * ms_per_mb
举个例子：
如果当前的某个软引用 A，它的 timestamp值为 2000ms，上一次 GC的 clock时间是 5000ms，ms_per_mb常量的大小是 1000，空闲的堆空间为 1MB，那么，计算可得
5000 - 2000 <= 1 * 1000 是假的，返回 false
所以我们需要清理掉这个软引用。
那么如果假设堆空间比较大，比如是 4MB，那么计算可得
5000 - 2000 <= 4 * 1000 是真的
所以我们不需要清理这个软引用
需要注意到的是：
一个软引用在一次访问之后，至少会存活一次 GC。
因为：
interval的值是我们通过 clock和 timestamp计算出来的，而 clock是上一次的 FGC时间，既然有上一次的 GC，说明它肯定至少得活过一次 GC呀。
此外，每当一个引用在某次垃圾回收之后被访问到了，那么 timestamp的值会被设置成和 clock一样，然后 interval就变成了 0，软引用就肯定不会被回收了。
想想也是的呀，针对经常在用的对象，我们肯定是要保留的呀。</softreference
