聊聊ThreadLocal（二）-编程知识

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

大部分面试官喜欢问ThreadLocal，却错误地以为东西是存在ThreadLocal中，并且笃定key是当前线程...

其实Java的线程共享机制，最重要的是Thread中的ThreadLocalMap，ThreadLocal其实不重要，它只是一个钩子。东西实际被存在每一个Thread的ThreadLocalMap中，所以广义上可以理解为东西是存在Thread中。关于三者的关系，急性子的朋友可以直接先拉到文章末尾看看那张图。

ThreadLocal.set(T value)的key是Thread吗？

首先，要更新一下大家固有的认知：ThreadLocal其实不存东西，ThreadLocalMap的key也不是Thread。

很多人，包括很多面试官，都认为ThreadLocal在执行set(T value)时是把当前线程作为key存入自己内部的map中，大致相当于这样：

为什么他们会这样认为呢？大概是因为他们“看过”set(T value)的源码：

createMap(t, value)，我去，这不就是传入一个Thread和value然后在内部构建一个Map吗？不用想了，ThreadLocal内部肯定有个Map，key就是Thread！

但真的是这样吗？

实际上，如果你点进createMap()会发现：

t.threadLocals其实是Thread内部的ThreadLocalMap，这里正在给Thread的ThreadLocalMap赋值呢，而且ThreadLocalMap的key是this，也就是当前ThreadLocal，而不是Thread。

是不是打破三观，甚至觉得有点懵？没关系，下面才是正文开始，会慢慢解释ThreadLocal的来龙去脉。

如何理解ThreadLocal是一个钩子？

如上图，Thread t1被实例化后，其实内部有个ThreadLocalMap，刚开始是null。然后t1.start()后线程就开始跑了（沿着箭头），当线程执行到

ThreadLocal tl1 = new ThreadLocal(); 
t1.set("你好");

时，ThreadLocal会作为一个钩子，尝试从Thread t1中钩出ThreadLocalMap。如果发现这个成员变量尚未赋值，则new ThreadLocalMap()并把map设置进去。特别注意，由于set()是ThreadLocal的方法，所以map.set(this, value)中的this显然是ThreadLocal tl1。

所以，ThreadLocalMap的key并不是Thread，而是ThreadLocal！！！

此时此刻，内存中有三个对象，Thread t1、ThreadLocal tl1、ThreadLocalMap map，其中Thread的成员变量map指向堆中新建的ThreadLocalMap。

你可以理解为：

ThreadLocal是紫霞仙子，而Thread是至尊宝，500年前在花果山的时候，紫霞一剑劈开至尊宝的胸膛（getMap），看看他有没有心（ThreadLocalMap）。此时发现至尊宝没有心，于是造了一颗心并且在心里留下一滴眼泪（紫霞：泪水）

对着上面的流程图，看看是不是这么回事。

调用threadLocal.get()到底发生了什么？

500年后，至尊宝走啊走，走到了盘丝洞，又遇到了紫霞仙子（ThreadLocal），紫霞再次劈开了至尊宝的胸膛（getMap），发现已经有心了，于是在至尊宝的心里找到名为“紫霞”的那滴泪水。

至此，大家已经明白同一个thread是如何在Controller存入值，然后在Service取出值的。

多个Thread与同一个ThreadLocal

上面讲的是一个Thread和一个ThreadLocal。接下来，我们探究一下多个Thread与同一个ThreadLocal：为什么访问同一个threadLocal.get()，Thread1存入的值不会被Thread2取出来？

其实很简单，你想想，同一个ThreadLocal表示从始至终只有一个紫霞仙子，而Thread1和Thread2可以看做是至尊宝和孙悟空。

至尊宝见到紫霞--->threadLocal.set()，紫霞劈开至尊宝的胸膛，造了一颗心并留下泪水（紫霞：泪水）--->紫霞把心（map）塞回至尊宝胸膛

孙悟空见到紫霞--->threadLocal.set()，紫霞劈开孙悟空的胸膛，造了一颗心并留下泪水（紫霞：紫青宝剑）--->紫霞把心（map）塞回孙悟空胸膛

至尊宝又见到紫霞，紫霞拿出 至尊宝的心，取出泪水。

孙悟空又见到紫霞，紫霞拿出 孙悟空的心，取出紫青宝剑。

至尊宝和孙悟空不是同一个人啊，紫霞分别在他们心里放的东西，怎么会串起来呢？

多个Thread与多个ThreadLocal

至尊宝见到紫霞--->threadLocal.set()，紫霞劈开至尊宝的胸膛，造了一颗心并留下泪水（紫霞：泪水）--->紫霞把心（map）塞回至尊宝胸膛

孙悟空见到紫霞--->threadLocal.set()，紫霞劈开孙悟空的胸膛，造了一颗心并留下泪水（紫霞：紫青宝剑）--->紫霞把心（map）塞回孙悟空胸膛

至尊宝又见到紫霞，紫霞拿出至尊宝的心，取出泪水。

孙悟空又见到紫霞，紫霞拿出孙悟空的心，取出紫青宝剑。

悟空去取西经了，杀青了，暂时先忘了他。

至尊宝（Thread）和紫霞（ThreadLocal）快乐地生活着，此时他的心里（ThreadLocalMap）有一颗紫霞的泪水。但有一天他在菜市场遇到了初恋白晶晶（另一个ThreadLocal），白晶晶劈开至尊宝的胸膛，发现已经有心了（ThreadLocalMap），就不造心了，而是在里面又留下一滴泪（白晶晶：泪水）

也就是说，一个Thread只能有一个ThreadLocalMap，第一次遇到的ThreadLocal会帮它创建一个Map塞进去，往后无论遇到多少个ThreadLocal，都是直接用那个Map，而且都是把自己作为key，往Map里存东西。

如果你顺着箭头看，会发现thread-0只能访问threadLocalMap@111，thread-1只能访问threadLoocalMap@222，因为ThreadLocalMap本质是每个Thread内部各存一份，互不干扰。Thread在遇到不同的ThreadLocal，可以把ThreadLocal自身作为key存入map或从map中取出value。

ThreadLocalMap与WeakReference

在Java中有4种引用类型：强、软、弱、虚。

强引用不受GC影响，除非引用全部切断。比如 Student s = new Student()，假设当前只有s指向Student对象，那么当s=null时，Student对象会在下次GC时被回收
软引用对象会在内存不足触发GC时被回收（适用于高速缓存）
弱引用是每次GC时都回收，不论内存是否不足
虚引用（堆外内存，比如zerocopy）

对于Map，每一个键值对被称为Entry，相信大家都知道。

为什么ThreadLocalMap的Entry要继承弱引用呢？

在回答这个问题之前，我们先来了解下弱引用是怎么玩的：

也就是说，当一个对象被WeakReference包装后，它就产生了一个弱引用指向它。此时即使把强引用切断，仍然有弱引用连接着。但是由于弱引用的特性，这个对象会在下次被GC线程被直接回收。

让我们再次回到ThreadLocalMap，虽然Entry继承自WeakReference，但并不是说Entry本身是弱引用，而是Entry的key是弱引用：

那么，ThreadLocalMap为什么要把key包装成弱引用呢？

如果ThreadLocalMap的key不使用Weak Reference，那么堆中的ThreadLocal对象同时存在多处强引用，即使我们把外面的threadLocal设置为null，但ThreadLocalMap中的引用仍然指向堆中的ThreadLocal。最终可能造成内存泄露（无法彻底释放ThreadLocal对象，因为始终有引用指向它）。

而如果key是弱引用，一旦在某一刻，外界所有强引用都被切断（外面的ThreadLocal被置为null），当前只有弱引用指向ThreadLocal对象，那么不久的将来（下一次GC）ThreadLocal对象就会被回收。

ThreadLocalMap与内存泄露

以为我讲重复了吗？上面不是已经用弱引用解决了吗？！

并没有。

原本引入Weak Reference是为了解决多个强引用导致ThreadLocal对象无法回收的问题，但一个解决策略的引入往往伴随着新bug的产生。试想一下，当外部强引用都切断后下一次GC回收了ThreadLocal对象，此时Entry的key会变成什么？

key = null;

当tl1变成null，ThreadLocalMap的Entrys变成下面这样：

null : value1（Entry1）
tl2 : value2（Entry2）
tl3 : value3（Entry3）

从此以后Entry1再也没有人能回收了，因为tl1已经被回收，这个key没了，自然也就无法根据key清除value了。C/C++中有“野指针”的概念，所以我喜欢把这种情况称为“野Entry”。

在引入弱引用前，我们担心的是ThreadLocal一直无法被释放造成内存泄漏，而引入了WeakReference后虽然解决了ThreadLocal的内存泄露，却可能导致Entry的内存泄露，因为当key变成null后，我们无法再根据key移除value了。

实际上，ThreadLocalMap也发现了这个问题，它会在每次get/set时判断key，如果key为null，则把value也归置为null：

但是这种策略是不保险的，因为它的前提是下一次使用时把上一次遗留的key为null的value清除。如果我再也不用，是不是仍然无法移除呢？

所以最保险的方法是，每次使用完毕都及时清除。

ThreadLocal<String> tl = new ThreadLocal<>(); 
tl.set("紫霞"); 
// ...经历过好多事 
tl.remove()

remove()是ThreadLocal的方法，this指的是threadLocal，就是从Map中根据key删除value。

tl1 : value1 （根据key把value清空）
tl2 : value2
tl3 : value3

实际编程时有些公司喜欢在拦截器中取出用户信息放入线程，对此个人建议可以在拦截器的preHandle()中set，在afterCompletion()中remove()。

最后，一张图总结Thread、ThreadLocal和ThreadLocalMap：

---------------------------------------------------------------------------------------------------------------------------------

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

进群，大家一起学习，一起进步，一起对抗互联网寒冬