背景
工程中用到guava的本地缓存。它底层实现和API接口上使用了强引用、软引用、弱引用。所以温故知新下，也夯实下基础。
预备知识
先来看下GC日志每个字段的含义
Young GC示例解释
[GC (Allocation Failure) [PSYoungGen: 273405K->20968K(278016K)] 480289K->473619K(737792K), 0.1090103 secs] [Times: user=0.19 sys=0.27, real=0.11 secs]
解释
[GC(产生GC的原因，例子中是由于分配内存失败) [PSYoungGen: 年轻代回收前空间->年轻代回收后空间(年轻代总空间)] 堆区的回收前空间->堆区的回收后空间(堆区的总空间), GC耗时] [Times: 用户空间耗时 系统空间耗时, 实际耗时]
**Full GC示例解释 **
[Full GC (Ergonomics) [PSYoungGen: 20968K->20805K(278016K)] [ParOldGen: 452651K->451654K(864256K)] 473619K->472460K(1142272K), [Metaspace: 5793K->5793K(1056768K)], 0.1565987 secs] [Times: user=0.70 sys=0.00, real=0.16 secs]
解释
[Full GC (产生GC原因，例子中是由于要放入老年代的对象超过了老年代的剩余空间) [PSYoungGen: ->年轻代回收前空间->年轻代回收后空间(年轻代总空间)] [ParOldGen: 老年代回收前空间->老年代回收后空间(老年代总空间)] 堆区的回收前空间->堆区的回收后空间(堆区的总空间), [Metaspace: 元空间的回收前空间->元空间的回收后空间(元空间的总空间)], GC耗时] [Times: 用户空间耗时 系统空间耗时, 实际耗时]
创建一个10M的大对象，重写finalize方法。finalize()方法会在对象被回收前调用，一个对象只有一次被调用的机会。对象可以在这个方法里进行自救，逃过被垃圾回收。Java设计这个方法可以被覆写是为了让有些对象在回收前做一些检查，完成一些前置条件再被垃圾回收。正式代码不建议使用。因为是测试，所以为了验证效果，这里打印GC日志信息。
byte[] bytes = new byte[10 * 1024 * 1024];
int index;
public Ref(int index) {
this.index = index;
}
public byte[] getBytes() {
return bytes;
}
@Override
public void finalize() {
System.out.println("index " + index + "'s " + bytes.length + "is going to be GG");
}
为了测试，JVM参数统一为-Xms20M -XX:+PrintGCDetails。Xms20M表示堆内存设置最大为20M，-XX:+PrintGCDetails代表打印详细的GC信息。
image
强引用
image.png
这段代码由上线的设置可知，由于最大设置20M堆空间，所以很快触发了GC。
image
不过Xmx这个值是建议内存最大使用值。如果内存使用超过这个值，jvm认为还有内存可以使用，也会将对象一直往堆里面放。所以2次GC之后JVM自动扩容了，之后就不再频繁GC。最终用到了满足程序需要的内存。
image
强引用是直接new出来调用的对象，大家都知道。由上面实验可知，在系统内存很富裕的情况下，因为强引用内存不能被释放，所以会多申请了很多内存。
软引用
软引用会在系统将要发生内存溢出异常之前，将会把这些软引用对象列进回收范围进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
用实验说明一下，为了防止JVM自动调整堆大小，我们把堆设置-Xmx200M。
image.png
从下面实验结果可以看到数次的 GC之后，内存要撑不住的时候，Ref的软引用对象触发了finalize方法。这意味着它将要被内存回收了。说明GC会引发软引用里对象的内存回收，即使这个软引用本身还被强引用(list调用)着。
image
最终回收了这些内存也不能避免OOM的结局：
image
因为软引用通常情况下就是这样，只有内存马上要溢出了才触发它的GC。就好像扁鹊见蔡桓公的时候，蔡桓公的病已经很深了，马上就没救了。所以有了下面弱引用的方法：有病早治。
弱引用
弱引用是发生了一次垃圾回收后，既存的弱引用对象就开始回收。通常，一个弱引用对象仅能生存到下一次垃圾回收前。
用实验说明一下，为了防止JVM自动调整堆大小，我们把堆设置-Xmx200M。
image.png
从下面的实验结果可知在发生了一次GC之后，已经生成的软引用对象都都回收了。下一次GC，这中间产生的软引用对象也都被回收了。
image
最终，由于GC及时，整个过程没有爆发OOM，平安的结束了。
image
虚引用
虚引用也叫幻影引用。任何时候可能被GC回收，就像没有引用一样。
并且他必须和引用队列一起使用，用于跟踪垃圾回收过程，当垃圾回收器回收一个持有虚引用的对象时，在回收对象后，将这个虚引用对象加入到引用队列中，用来通知应用程序垃圾的回收情况。
先来实验一下，从下面结果可看到从一开始取出来就是空对象，基本上刚创建出来就被回收了。
image
一个像是从来没有存在过的幻影有什么用呢？Java的Unsafe类和NIO都可以直接访问堆外内存。堆外内存GC管不了，这时候虚引用就排上用场了。我们可以通过引用队列跟踪垃圾回收，做好善后。
在Guava中使用强软弱引用
@Test
public void testStrong() {
Cache<Integer, Ref> cache = CacheBuilder.newBuilder().expireAfterAccess(1, TimeUnit.DAYS).build();
for(int i=0; i<100; i++) {
cache.put(i, new Ref(i));
System.out.println(cache.getIfPresent(i));
}
System.out.println(cache.stats().loadSuccessCount());
}
@Test
public void testSoft() {
Cache<Integer, Ref> cache = CacheBuilder.newBuilder().softValues().build();
for(int i=0; i<100; i++) {
cache.put(i, new Ref(i));
System.out.println(cache.getIfPresent(i));
}
}
@Test
public void testWeak() {
Cache<Integer, Ref> cache = CacheBuilder.newBuilder().weakKeys().weakValues().build();
for(int i=0; i<100; i++) {
cache.put(i, new Ref(i));
System.out.println(cache.getIfPresent(i));
}
}
Guava在没有显示设置强、软、弱引用的情况下默认是强引用。这个结论我没有看任何书，而是通过跟踪源码，debug得到的结论。当显示设置为软引用或者弱引用时，运行时GC触发和对象回收之间的关系和自己手动直接测试的结果是一样的，大家可以动手实践下。
总结
Java的强软弱虚引用被回收的时机不同：强引用是引用被释放才会回收；软引用是没释放，但是快OOM了就会被回收；弱引用是引用没释放，但是发生了GC后就会被回收；虚引用随时会回收，好像没有存在过，但是会有一个队列来跟踪它的垃圾回收情况。
网友评论