作者简介:大家好,我是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中,大致相当于这样:
为什么他们会这样认为呢?大概是因为他们“看过”threadLocal.set(T value)的源码:
ThreadLocal tl1 = new ThreadLocal();
t1.set("你好");
createMap(t, value),我去,这不就是传入一个Thread和value然后在内部构建一个Map吗?不用想了,ThreadLocal内部肯定有个Map,key就是Thread!
但真的是这样吗?
NO,我们先不管map是哪来的,直接看if(map != null)的逻辑:map.set(this, value),也就是把this作为map的key。
那么,这个this是谁呢?很明显,是ThreadLocal。
现在我们隐约了解到变量存在某个Map中,而且key是ThreadLocal。那么这个Map是谁?怎么来的?
答案就在createMap(t, value):t就是当前线程,由Thread.currentThread()得到。
哦!原来Map就是这么来的:通过createMap()方法new了一个ThreadLocalMap,并且做了初始化,把当前threadLocal对象作为key,firstValue作为value。
至此,我们解决了两个疑问:
- 有一个不知道来历的Map,变量都存在它那,key是ThreadLocal,而不是大部分人认为的Thread
- Map的类型是ThreadLocalMap,被赋值给Thread的一个字段:threadLocals
是不是有点懵?没关系,上面这段话就是来打破固有认知的,看不懂也没关系,我当初也绕了很久。
下面开始正文。
如何理解ThreadLocal是一个钩子?
如上图,Thread t1被实例化后,其实内部有个threadLocals字段,它其实是一个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,其中ThreadLocalMap在Thread内部,是ThreadLocal塞进去的。
你可以理解为:
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)塞回孙悟空胸膛
至尊宝又见到紫霞,紫霞拿出至尊宝的心,取出泪水。
孙悟空又见到紫霞,紫霞拿出孙悟空的心,取出紫青宝剑。
也就说,至尊宝和孙悟空各自都在路上遇到了紫霞,心里都存了东西。
至尊宝的心
{
"紫霞":"泪水"
}
孙悟空的心
{
"紫霞":"紫青宝剑"
}
ThreadLocal zixia = new ThreadLocal();
// 至尊宝
new Thread(()->{
// 遇到紫霞,紫霞往他心里塞了眼泪
zixia.set("泪水");
}).start();
// 孙悟空
new Thread(()->{
// 遇到紫霞,紫霞往他心里塞了紫青宝剑
zixia.set("紫青宝剑");
}).start();
至尊宝和孙悟空不是同一个人啊,紫霞分别在他们心里放的东西,怎么会串起来呢?
同一个Thread与多个ThreadLocal
至尊宝见到紫霞--->threadLocal.set(),紫霞劈开至尊宝的胸膛,造了一颗心并留下泪水(紫霞:泪水)--->紫霞把心(map)塞回至尊宝胸膛。
至尊宝(Thread)和紫霞(ThreadLocal)快乐地生活着,此时他的心里(ThreadLocalMap)有一颗紫霞的泪水。但有一天他在菜市场遇到了初恋白晶晶(另一个ThreadLocal),白晶晶劈开至尊宝的胸膛,发现已经有心了(ThreadLocalMap),就不造心了,而是在里面留下一段回忆(白晶晶:回忆)
此时至尊宝的心是这样的:
{
"紫霞":"泪水",
"白晶晶":"回忆"
}
也就是说,一个Thread只能有一个ThreadLocalMap,第一次遇到的ThreadLocal会帮它创建一个Map塞进去,往后无论遇到多少个ThreadLocal,都是直接用那个Map,而且都是把自己作为key,往Map里存东西。
ThreadLocal zixia = new ThreadLocal();
zixia.set("泪水");
ThreadLocal baijingjing = new ThreadLocal();
baijingjing.set("回忆");
线程你是看不到的,但可以想象一阵风吹过上面两个ThreadLocal对象,每个ThreadLocal对象都尝试把变量塞到风中,往下一个站点带去。
多个Thread与多个ThreadLocal
如果你顺着箭头看,会发现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的Entry要继承弱引用转为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
进群,大家一起学习,一起进步,一起对抗互联网寒冬