头条二面:你确定 ThreadLocal 真的会造成内存泄露?

ThreadLocal 是 Java面试过程中的“钉子户”,在网上也充斥着各种有关ThreadLocal内存泄露的问题。本文换个角度,先思考 ThreadLocal 体系中的 ThreadLocalMap 为什么要设计成弱引用。

1. ThreadLocal 知识体系

本文还是不能免俗,在回答这个问题之前需要先和大家介绍一下 ThreadLocal 的知识,使大家对 ThreadLocal 有一个相对全面的认识。

ThreadLocal 本地线程变量,主要用于解决数据访问的竞争,通常用于多租户、全链路压测、链路跟踪中保存线程上下文环境,在一个请求流转中非常方便的获取一些关键信息,例如当前的租户信息、压测标记。

ThreadLocal 正如其名,本地线程变量,即数据存储在线程自己的局部变量中。

其整体架构如下图所示:

头条二面:你确定 ThreadLocal 真的会造成内存泄露?_第1张图片

ThreadLocal 的核心设计理念总结如下:

  • 每一个线程对象会维护一个私有属性:ThreadLocal.ThreadLocalMap threadLocals;

  • ThreadLocalMap 内部结构为 Key-Value 键值对,其 Key 为 ThreadLocal 对象,Value 为调用 ThreadLocal 的 set 方法设置的值。

一言以蔽之:ThreadLocal是将线程需要访问的数据存储在线程对象自身中,从而避免多线程的竞争。

2。为什么会被设计为弱引用呢?

接下来我们来看一下 ThreadLocalMap 的声明:

头条二面:你确定 ThreadLocal 真的会造成内存泄露?_第2张图片


什么?Map 中的用于存储键值对的 Entry 为什么要继承 WeakReference?

思考这个问题之前先和大家普及一下 Java 的四种引用类型,主要是在垃圾回收时 Java虚拟机会根据不同的引用类型采取不同的措施。

  • 强引用:Java 默认的引用类型,例如 Object a = new Object(); 其中 a 为强引用,new Object() 为一个具体的对象。一个对象从根路径能找到强引用指向它,JVM 虚拟机就不会回收;

  • 软引用(SoftReference):进行年轻代的垃圾回收不会触发 SoftReference 所指向对象的回收;但如果触发 Full GC,那 SoftReference 所指向的对象将被回收;备注:是除了软引用之外没有其他强引用引用的情况下。

  • 弱引用(WeakReference):如果对象除了有弱引用指向它后没有其他强引用关联它。当进行年轻代垃圾回收时,该引用指向的对象就会被垃圾回收器回收;

  • 虚引用(PhantomeReference):该引用指向的对象,无法对垃圾收集器收集对象时产生任何影响,但在执行垃圾回收后垃圾收集器会通过注册在 PhantomeReference 上的队列来通知应用程序对象被回收。

从四种弱引用的实际作用来说,主要是与垃圾回收器配合,决策什么时候可以将被引用的对象回收。

理论看起来有点晦涩难懂,接下来笔者将以图解的方式,争取将该问题阐述清楚。

头条二面:你确定 ThreadLocal 真的会造成内存泄露?_第3张图片


根据第一部分,声明了一个 TheadLocal 对象,并且一个线程通过调用 threadLocal 对象的 set(Object value) 存储了一个对象。其引用如上图所示。

ThreadLocal 的设计比较晦涩难懂,究其原因是我们通过 threadLocal 对象的 set 方法进行存储值,但数据并不是存储在 ThreadLocal 对象中,而是存储在当前调用该方法的线程对象中。但从应用者的角度来看,我们操作的对象是 ThreadLocal,从设计上来说就应该为它考虑。

试问一个问题:如果应用程序觉得 ThreadLocal 对象的使命完成,将 threadLocal ref 设置为 null,如果 Entry 中引用 ThreadLocald 对象的引用类型设置为强引用的话,会发生什么问题?

答案是:ThreadLocal 对象会无法被垃圾回收器回收。因为从 thread 对象出发,有强引用指向 threadlocal obj。此时会违背用户的初衷,造成所谓的内存泄露。

由于 ThreadLocalMap 中的 key 是指向 ThreadLocal,故从设计角度来看,设计为弱引用。将不会干扰用户的释放 ThreadLocal 意图。

3. 大量Entry造成的内存溢出问题探讨

亮出了自己的观点,接下来我们再延伸一下,想再来谈谈网络上关于ThreadLocalMap中存储大量 Entry 对象导致的内存“泄露”问题。

温馨提示:本节仅代表我当前的观点,希望各位读者朋友们带着批判与辨证的思维来一起看待问题,而不是人云亦云。

网络观点:在使用 ThreadLocal 中 set 方法与 remove 方法需要成对执行,需要没有执行 remove 方法会造成内存泄露?甚至造成内存溢出?

本文观点:当然能成对使用当然更好,但在实际情况中,其实不调用 remove 方法也不太容易造成内存溢出

因为从存储结构来看,除非创建海量线程,并且这些线程都不释放,导致大量线程内部持有的 ThreadLocalMap 中对象一直不会释放,但一个线程所持有的 Entry 对象个数不多,取决于关联的 ThreadLocal 对象个数,故我们需要的关注点而不是 remove 方法,而是防止线程资源泄露。

你可能感兴趣的:(●面试相关,并发多线程,java)