头条二面：你确定 ThreadLocal 真的会造成内存泄露？
ThreadLocal 的核心设计理念总结如下：
每一个线程对象会维护一个私有属性:ThreadLocal.ThreadLocalMap threadLocals。
ThreadLocalMap 内部结构为 Key-Value 键值对，其 Key 为 ThreadLocal 对象，Value 为调用 ThreadLocal 的 set 方法设置的值。
一言以蔽之：ThreadLocal 是将线程需要访问的数据存储在线程对象自身中，从而避免多线程的竞争。
接下来我们来看一下 ThreadLocalMap 的声明：
什么？Map 中的用于存储键值对的 Entry 为什么要继承 WeakReference？
思考这个问题之前先和大家普及一下 Java 的 4 种引用类型，主要是在垃圾回收时 java 虚拟机会根据不同的引用类型采取不同的措施。
强引用：java 默认的引用类型，例如 Object a = new Object();其中 a 为强引用，new Object()为一个具体的对象。一个对象从根路径能找到强引用指向它，jvm 虚拟机就不会回收。
软引用(SoftReference)：进行年轻代的垃圾回收不会触发 SoftReference 所指向对象的回收；但如果触发 Full GC，那 SoftReference 所指向的对象将被回收。备注：是除了软引用之外没有其他强引用引用的情况下。
弱引用(WeakReference) :如果对象除了有弱引用指向它后没有其他强引用关联它，当进行年轻代垃圾回收时，该引用指向的对象就会被垃圾回收器回收。
虚引用(PhantomeReference) 该引用指向的对象，无法对垃圾收集器收集对象时产生任何影响，但在执行垃圾回收后垃圾收集器会通过注册在 PhantomeReference 上的队列来通知应用程序对象被回收。
从四种弱引用的实际作用来说，主要是与垃圾回收器配合，决策什么时候可以将被引用的对象回收。
理论看起来有点晦涩难懂，接下来笔者将以图解的方式，争取将该问题阐述清楚。
根据第一部分，声明了一个 TheadLocal 对象，并且一个线程通过调用 threadLocal 对象的 set(Object value)存储了一个对象，其引用如上图所示。
**ThreadLocal 的设计比较晦涩难懂，究其原因是我们通过 threadLocal 对象的 set 方法进行存储值，但数据并不是存储在 ThreadLocal 对象
中，而是存储在当前调用该方法的线程对象中。但从应用者的角度来看，我们操作的对象是 ThreadLocal，从设计上来说就应该为它考虑。**
试问一个问题：如果应用程序觉得 ThreadLocal 对象的使命完成，将 threadLocal ref 设置为 null，如果 Entry 中引用 ThreadLocald 对象的引用类型设置为强引用的话，会发生什么问题？
答案是：ThreadLocal 对象会无法被垃圾回收器回收，因为从 thread 对象出发，有强引用指向 threadlocal obj。此时会违背用户的初衷，造成所谓的内存泄露。
由于 ThreadLocalMap 中的 key 是指向 ThreadLocal，故从设计角度来看，设计为弱引用，将不会干扰用户的释放 ThreadLocal 意图。
亮出了自己的观点，接下来我们再延伸一下，想再来谈谈网络上关于 ThreadLocalMap 中存储大量 Entry 对象导致的内存“泄露”问题。
温馨提示：本节仅代表我当前的观点，希望各位读者朋友们带着批判与辨证的思维来一起看待问题，而不是人云亦云。
网络观点：在使用 ThreadLocal 中 set 方法与 remove 方法需要成对执行，需要没有执行 remove 方法会造成内存泄露？甚至造成内存溢出？
我的观点：当然能成对使用当然更好，但在实际情况中，其实不调用 remove 方法也不太容易造成内存溢出，因为从存储结构来看，除非创建海量线程，并且这些线程都不释放，导致大量线程内部持有的 ThreadLocalMap 中对象一直不会释放，但一个线程所持有的 Entry 对象个数不多，取决于关联的 ThreadLocal 对象个数，故我们需要的关注点而不是 remove 方法，而是防止线程资源泄露。
最后推荐一篇关于笔者在实践全链路压测时对 ThreadLocal 进行的调研与方案。
一键三连(关注、点赞、留言)是对我最大的鼓励。
还未添加个人签名 2021.11.08 加入
还未添加个人简介
评论