ThreadLocal 线程本地变量,算是Java开发中比较常用的API了,今天我们来一探究竟
使用场景
ThreadLocal 适用于每个线程需要自己独立的实例且该实例需要在多个方法中被使用,也就是变量在线程间隔离,而在同一线程共享的场景。例如管理Connection,我们希望每个线程只使用一个Connection实例,这个时候用ThreadLocal就很合适。
1 | public class ThreadLocalDemo { |
还有之前写过的一篇动态切换数据源 https://www.jianshu.com/p/0a485c965b8b,AOP 通过 ThreadLocal 保存当前线程需要访问的数据源的key,AbstractRoutingDataSource 再通过 ThreadLocal 中的数据切换到指定的数据源,对业务代码毫无入侵
原理
在我们了解了如何使用之后,来看下 ThreadLocal 是如何实现的
ThreadLocal.get()
我们从get方法来分析,可以看到方法中获取当前线程,并通过当前线程得到一个 ThreadLocalMap
,我们可以暂时把这个ThreadLocalMap 理解为我们熟悉的HashMap,然后通过 this(当前ThreadLocal对象)作为key,从Map中获取Entry
我们再来看下,ThreadLocalMap 以及ThreadLocalMap.Entry 中的核心成员变量,ThreadLocalMap 中实现了一个简单的hash表
看到这里你可能还不是很清晰,结合下面这张图理解一下,每个线程(Thread对象)中有一个ThreadLocalMap,使线程之间的数据天然隔离,ThreadLocalMap 有一张hash表 Entry[],每个 Entry 中对应存储着一个ThreadLocal实例 - value,这样使得不同的ThreadLocal 对象之间也形成了隔离
ThreadLocalMap 中的hash表
我们通过 ThreadLocalMap.set() 来了解下内部的hash表是如何实现的
线性探测是指当发生hash冲突时,利用固定的算法寻找一定步长的下个位置(ThreadLocal中发生hash冲突时,index+1),依次判断,直至找到能够存放的位置
如果线程中操作了大量的 ThreadLocal 对象,势必会造成hash冲突,这是没有必要的性能开销,如果可以的话,我们可以只保留一个ThreadLocal对象
关于 ThreadLocal 的一些思考
- 为什么要使用弱引用
图3中,我们看到hash表中会出现 key == null
的Entry,这是因为 ThreadLocalMap.Entry 的key (Entry 对ThreadLocal设置了弱引用,可以回顾一下图2)
弱引用的对象拥有更短暂的生命周期。在GC时,一旦发现了对象只具有弱引用,这个对象一定被回收
这么做的原因:如果ThreadLocal 对象需要被回收时(此时并没有调用ThreadLocal.remove),线程中的ThreadLocalMap 一直强引用着 ThreadLocal对象,这会让 ThreadLocal对象 以及对应的value对象内存无法释放,导致内存泄漏。这算是ThreadLocal的一种容错机制,这样做使得了ThreadLocal对象得到了回收,但是value的内存并没有释放,所以ThreadLocalMap 的get、set方法中都会去尝试清理ThreadLocal已经被回收的entry。
- 使用过后不及时remove会怎么样
很多博客中都强调了,ThreadLocal.remove的重要性。举个例子,我们新启了一个线程在这个线程中使用了ThreadLocal,我们并没有调用remove,这会导致存储的value对象一直没有办法被回收,直到线程被销毁
- 线程池中也需要remove吗
以web线程池为例,如果每次都在过滤器中操作同一个ThreadLocal.set,然后业务代码中get,似乎没什么问题。计算出的hash值都是一样的,槽位也是一样的会覆盖上一次的值。确实业务不会有问题,但是还是推荐大家在使用完之后remove,因为这样会让无用的value对象早点被回收,在很多java源码中都会看到,对一些不再使用的对象进行如下的help GC操作1
object = null // help GC
所以我们也需要让无用的对象失去引用,帮助GC
- 综上所述
ThreadLocal 使用过后要及时remove,帮助JVM释放内存