ThreadLocaljava面试过程中的“钉子户”在网上也充斥着各种有关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方法而是防止线程资源泄露。