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

大家好，我是威哥，《RocketMQ技术内幕》一书作者，荣获RocketMQ官方社区优秀布道师、CSDN2020博客执之星Top2等荣誉称号。目前担任中通快递技术平台部资深架构师，主要负责全链路压测、消息中间件、数据同步等产品的研发与落地，拥有千亿级消息集群的运维经验，不仅实践经验丰富，而且对其源代码有深入且系统的研究。欢迎大家关注我，一起抱团发展。

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

1、ThreadLocal知识体系

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

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

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

其整体架构如下图所示：

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

• 每一个线程对象会维护一个私有属性:ThreadLocal.ThreadLocalMap threadLocals。
• ThreadLocalMap内部结构为Key-Value键值对，其Key为ThreadLocal对象，Value为调用ThreadLocal的set方法设置的值。

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

2、为什么会被设计为弱引用呢？

接下来我们来看一下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意图。

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

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

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

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

我的观点：当然能成对使用当然更好，但在实际情况中，其实不调用remove方法也不太容易造成内存溢出，因为从存储结构来看，除非创建海量线程，并且这些线程都不释放，导致大量线程内部持有的ThreadLocalMap中对象一直不会释放，但一个线程所持有的Entry对象个数不多，取决于关联的ThreadLocal对象个数，故我们需要的关注点而不是remove方法，而是防止线程资源泄露。

最后推荐一篇关于笔者在实践全链路压测时对ThreadLocal进行的调研与方案。

全链路压测流量染色解决方案

一键三连(关注、点赞、留言)是对我最大的鼓励。

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家早日进入互联网大厂。

Java进阶之梯，成长路线与学习资料，助力突破中间件领域

部分精彩文章推荐

1. 知乎高赞：如果一个程序员工作5年后还没成为大牛，是不是该考虑别的路子了？
2. 优秀程序员的源码阅读方法

打造完备分布式架构体系

1. 源码分析RocketMQ专栏(40篇+)
2. 源码分析Sentinel专栏(12篇+)
3. 源码分析Dubbo专栏(28篇+)
4. 源码分析Mybatis专栏
5. 源码分析Netty专栏(18篇+)
6. 源码分析JUC专栏
7. 源码分析Elasticjob专栏
8. Elasticsearch专栏（20篇+）
9. 源码分析MyCat专栏
10. 源码分析Canal专栏

文章来源: blog.csdn.net，作者：中间件兴趣圈，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/prestigeding/article/details/119858688