文章目录
- 1、引用之强软弱虚
- 2、强引用
- 3、软引用
- 4、弱引用
- 5、虚引用
- 6、ThreadLocal回顾
- 7、ThreadLocal使用弱引用的原因
- 8、清除脏Entry
- 9、最佳实践
不再会被使用的对象或者变量占用的内存不能被回收,就是内存泄露(累积可能导致OOM)。
1、引用之强软弱虚
- Reference:强引用
- SoftReference:软引用
- WeakReference:弱引用
- PhantomReference:虚引用
Java 允许使用 finalize方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作(遗言时机)。
//since Java9,已过期
public class MyObject {@Overrideprotected void finalize() throws Throwable {//finalize用于在对象被不可撤销的丢弃之前执行的操作System.out.println("----invoke finalize method ~");}
}
2、强引用
当内存不足,JVM开始垃圾回收,对于强引用的对象,就算是出现了OOM也不会对该对象进行回收,死都不收。
强引用是最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还“活着”,垃圾收集器不会碰这种对象
//eg:
Student student = new Student();
-
在Java 中最常见的就是强引用,把一个对象赋给一个引用变量,这个引用变量就是一个强引用
-
当一个对象被强引用变量引用时,它处于可达状态,它是不可能被垃圾回收机制回收的,即使该对象以后永远都不会被用到,JVM也不会回收
-
因此强引用是造成Java内存泄漏的主要原因之一
对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null,一般认为就是可以被垃圾收集的了(当然具体回收时机还是要看垃圾收集策略)。
public class ReferenceDemo {public static void main(String[] args) {MyObject myObject = new MyObject();System.out.println("gc before: " + myObject);myObject = null;//手动触发一次GCSystem.gc();System.out.println("gc after: " + myObject);}
}
调用finalize方法是另一线程,这里的打印顺序不用关注。
3、软引用
软引用是一种相对强引用弱化了一些的引用,需要用java.lang.ref.SoftReference类来实现,可以让对象豁免一些垃圾收集。
总之就是相对强引用而言,稍微松一点,GC触发时:
- 当系统内存充足时,它不会被回收
- 当系统内存不足时,它会被回收
软引用通常用在对内存敏感的程序中,比如高速缓存就有用到软引用,内存够用的时候就保留,不够用就回收。用SoftReference把自定义对象包装一下,对应的引用就变成了软引用。
SoftReference<MyObject> softReference = new SoftReference<>(new MyObject());
System.out.println("gc before: " + softReference.get());
//手动触发一次GC
System.gc();
System.out.println("gc after: " + softReference.get());
修改Demo类的JVM内存限制,创造一个内存不足的情况:
创建一个20M的数组,超过了上面的最大内存,模拟内存不足,对象被回收:
4、弱引用
对于只有弱引用的对象来说,只要垃圾回收机制一运行,不管JVM的内存空间是否足够,都会回收该对象占用的内存。
WeakReference<MyObject> weakReference = new WeakReference<>(new MyObject());
System.out.println("gc before: " + weakReference.get());
System.gc();
System.out.println("gc after: " + weakReference.get());
软引用和弱引用的适用场景举例:
假如有一个应用需要读取大量的本地图片,如果每次读取图片都从硬盘读取则会严重影响性能,如果一次性全部加载到内存中又可能造成内存溢出,此时使用软引用可以解决这个问题。
设计思路是:
用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系,在内存不足时,JVM会自动回收这些缓存图片对象所占用的空间,从而有效地避免了OOM的问题。
Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>().
5、虚引用
1)虚引用必须和引用队列ReferenceQueue联合使用
- 虚引用需要java.lang.ref.PhantomReference类来实现
- 虚,即形同虚设
- 虚引用不会决定对象的生命周期
- 如果一个对象仅持有虚引用,则它和没任何引用一样,随时都可能被垃圾回收器回收
- 不能单独使用,也不能通过它访问对象
- 虚引用必须和引用队列ReferenceQueue联合使用,如果虚引用对象被干掉了,就装到队列里
2)PhantomReference虚引用的get方法总是返回null
- 虚引用的主要作用是跟踪对象被垃圾回收的状态,仅仅是提供了一种确保对象被 finalize以后,做某些事情的通知机制
- PhantomReference的get方法总是返回null,因此无法访问对应的引用对象
3)处理监控通知使用
- 设置虚引用关联对象的唯一目的,就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理,用来实现比finalize机制更灵活的回收操作
构造方法:
//传入要包装的对象和引用队列
PhantomReference(T referent, ReferenCeQueue<? super T> queue)
继续设置JVM最大内存10M:
public class ReferenceDemo {public static void main(String[] args) {MyObject myObject = new MyObject();ReferenceQueue<MyObject> referenceQueue = new ReferenceQueue<>();PhantomReference<MyObject> phantomReference = new PhantomReference<>(myObject, referenceQueue);List<byte[]> list = new ArrayList<>();new Thread(() -> {while (true){list.add(new byte[1024 * 1024]); //1M//歇500ms,写1M进Listtry {TimeUnit.MILLISECONDS.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}//验证下每次get都是nullSystem.out.println(phantomReference.get() + " list add OK.");}},"t1").start();new Thread(() -> {while (true){Reference<? extends MyObject> reference = referenceQueue.poll();if(reference != null){System.out.println("有虚引用对象被回收,加入了队列");//break;}}},"t2").start();}}
开一个线程去占用内存,另开一个线程去查看队列,可以看到中途虚引用对应的对象被回收时,会加入到队列中。
6、ThreadLocal回顾
ThreadLocal是一个壳子,真正的存储结构是ThreadLocal里的ThreadLocalMap这个内部类,每个Thread对象维护着ThreadLocalMap的引用,ThreadLocalMap则用Entry来进行存储。
- 调用ThreadLocal的set方法时,实际上就是往ThreadLocalMap设置值,key是ThreadLoca对象,值Value是传递进来的对象
- 调用ThreadLocal的get方法时,实际上就是往ThreadLocalMap获取值,key是ThreadLocal对象
ThreadLocal本身并不存储值(ThreadLocal是一个壳),它只是自己作为一个key来让线程从ThreadLocalMap获取value。正因为这个原理,所以ThreadLocal能够实现线程间的"数据隔离",获取当前线程的局部变量值,不受其他线程影响
7、ThreadLocal使用弱引用的原因
public void function01(){//新建一个ThreadLocal对象,t1是强引用指向这个对象ThreadLocal<String> t1 = new ThreadLocal<>();//实际是创建了一个Entry对象,根据Entry源码知:Entry对象里的key(即ThreadLocal)是弱引用指向这个对象//当一个ThreadLocal实例对象只被Entry类实例(或者其它弱引用实例)引用时,它就会被GC回收t1.set("code9527");t1.get();
}
当function1方法执行完毕后,栈帧销毁,强引用 t1 也就没有了。但此时线程的ThreadLocalMap里某个entry的key引用还指向这个对象。此时:
-
若这个key引用是强引用,就会导致key指向的ThreadLocal对象,以及v指向的对象不能被gc回收,造成内存泄漏
-
若这个key引用是弱引用就大概率会减少内存泄漏的问题(还有一个key为nul的雷,在下面再展开)。
使用弱引用,就可以使ThreadLocal对象在方法执行完毕后顺利被回收且Entry的key引用指向为null,而此后我们调用get、set、remove方法时,就会尝试删除key为null的entry,可以释放value对象所占用的内存。
8、清除脏Entry
当我们为threadLocal变量赋值,实际上就是当前Entry(threadLocal实例为key,值为value)往这个threadLocalMap中存放。Entry中的key是弱引用,当threadLocal外部强引用被置为null(比如前面例子的t1=null),那么系统 GC 的时候,根据可达性分析,这个threadLocal实例就没有任何一条路能够引用到它, 这个ThreadLocal势必会被回收。
这样一来,ThreadLocalMap中就会出现key为nul的Entry,就没有办法访问这些key为nul的Entry的value,如果当前线程再迟迟不结束的话(线程池,线程在不断复用),这些key为null的Entry的value就会一直存在一条强引用:某个线程池中线程T1的引用Thread Ref ⇒ Thread ⇒ ThreadLocalMap ⇒ Entry ⇒ value ,因此永远无法回收,最后造成内存泄漏。
当然,如果当前thread运行结束,threadLocal、threadLocalMap、Entry没有引用链可达,在垃圾回收的时候都会被系统进行回收。
关于以上key为null的脏Entry的清除 ===> expungeStaleEntry方法
其中,get、set、remove等方法源码中,都有调用expungeStaleEntry方法,如get --> 调getEntry方法 --> getEntryAfterMiss方法:
虽然弱引用,保证了key指向的ThredLocal对象能被及时回收,但是v指向的value对象是需要ThreadLocalMap调用get、set时发现key为nul时才会去回收整个entry、value,因此弱引用不能100%保证内存不泄露,我们要在不使用某个ThreadLocal对象后,手动调用remoev方法来删除它,尤其是在线程池中,不仅仅是内存泄露的问题,因为线程池中的线程是重复使用的,意味着这个线程的ThreadLocalMap对象也是重复使用的,如果我们不手动调用remove方法,那么后面的线程就有可能获取到上个线程遗留下来的value值,造成bug。
总结:
- 弱引用保证ThreadLocal对象被及时回收,key为null的Entry会累积
- get、set时检查所有键为null的Entry对象并删除
9、最佳实践
- 【建议】创建ThreadLocal对象采用静态方法ThreadLocal.withInitial(() -> 初始值)
- 【建议】把ThreadLocal修饰为static(若某个属性所有对象都相同,则用静态变量,存方法区,如国籍,这样只在方法区保存一份,可避免不必要的内存空间浪费,反之,则是实例变量)
- 【强制】用完手动remove
最后,对ThreadLocal的总结:
- ThreadLocal 并不解决线程间共享数据的问题
- ThreadLocal 适用于变量在线程间隔离且在方法间共享的场景
- ThreadLocal 通过隐式的在不同线程内创建独立实例副本避免了实例线程安全的问题
- 每个线程持有一个只属于自己的专属Map并维护了ThreadLocal对象与具体实例的映射,该Map由于只被持有它的线程访问,故不存在线程安全以及锁的问题
- ThreadLocalMap的Entry对ThreadLocal的引用为弱引用,避免了ThreadLocal对象无法被回收的问题
- 都会通过expungeStaleEntry、cleanSomeSlots、replaceStaleEntry这三个方法回收键为 null 的 Entry对象的值 以及 Entry 对象本身,从而防止内存泄漏,属于安全加固的方法
- 群雄逐鹿起纷争,人各一份天下安