我之前一直认为自己还是比较了解Java中的四种引用的,直到前段时间有同事排查young gc问题,把一个本地缓存数据由WeakReference改成 SoftReference把young gc问题给解决了,我才意识到之前对着4中引用理解的不够透彻。
Java中引入 四种 引用的目的是让程序自己决定对象的生命周期,JVM是通过垃圾回收器对这四种 引用做不同的处理,来实现对象生命周期的改变。
1、强引用(StrongR eference)
强引用是 Java中最常见的,如果一个对象具有强引用,垃圾回收器宁愿抛出OOM也不会回收强引用。比如:
Object object = new Object();
object对象就是强引用。
如果 一个对象仅持有 软引用,内存空间足够,垃圾回收器就不会回收它;但是如果内存空间不足了,就会回收这些对象的内存。比如:
SoftReference<Object> softReference = new SoftReference<Object>(new Object());
其中softReference就是软引用。
应用场景: 常用于本地缓存。
例子:Mybatis中的本地缓存SoftCache就是使用 softReference模式,本地内存不足时会回收cache中的对象。
3、弱引用(WeakReference)
如果 一个对象仅持有 弱引用,当发生垃圾回收时,不管内存是否充分,都会将弱引用进行回收。
WeakReference<Object> weakReference = new WeakReference<Object>(new Object());
其中weakReference就是弱引用。
应用场景:很多资料说可用于本地缓存,但是我觉得用于本地缓存可能会GC带来副作用(在讲完弱引用对GC的影响之后你就明白了)。
例子:JDK中ThreadLocal就是使用的W eakReference,就是为了防止用户忘记调用remove,发生内存泄漏。
虚引用不会改变对象的生命周期,如果一个对象仅持有虚引用,那么它就和没有任何引用一样。
应用场景: 主要用于跟踪对象何时被回收,比如防止资源泄漏等;应用场景和finalize类似,但是这是一种 比finalizer更轻量更好的机制。
例子: DirectByteBuffer对象在创建的时候关联了一个PhantomReference(Cleaner),在这个子类中调用Unsafe的free接口来释放DirectByteBuffer对应的堆外内存块 。
引用和GC的关系如下图:
引用类型 |
GC回收时间 |
生存时间 |
---|---|---|
强引用 |
never |
一直存活知道JVM停止运行 |
软引用 |
内存不足时 |
内存不足时终止 |
弱引用 |
GC时 |
GC后终止 |
虚引用 |
unknown |
unknown |
对于软引用,只有在内存不足的时候才会影响到GC ,GC处理时类似于如下:
GC () {
if (内存不足) {
处理和回收软引用内存。
}
}
但是对于弱引用,每次GC的时候都需要处理弱引用。 GC处理时类似于如下 :
GC () {
处理和回收弱引用内存。
}
而在处理和回收引用时,通常需要两次GC才能完成, 在第一次GC时把引用加入到 queue队列。第二次GC的时候才会真正回收该对象。过程类似于finalize方法(参考: 从一个Young GC变慢的案例来聊聊finalize方法 )。
对于虚引用也有类似的过程。典型的mysql driver中链接使用了ConnectionPhantomReference追踪解决链接泄漏问题,但是也可能会导致GC 时间飚高。
一般情况下,不管是young GC还是CMS GC都会在GC日志中显示引用处理时间。比如 CMS GC如下:
如果我们发现处理时间太长,我们可以通过加入参数-XX:+PrintReferenceGC 。来定位是哪种引用时间处理太长。然后dump堆内内存,用MAT找到相关的引用,然后定位到代码解决问题。
如果代码层面实在没有办法优化的话,可以通过加入 -XX:+ParallelRefProcEnabled 参数加快引用处理。
也就是说一般情况下,软引用不会影响到GC(只有在内存不足时才会影响),但是弱引用会对GC产生比较强的明显,导致GC升高。所以说在使用本地cache的场景下尽量使用 弱引用 减少对GC产生的影响。