ThreadLocal是多线程编程的一个重要知识点,而且市场应用点非常多,例如Web系统Session的存储就是ThreadLocal一个典型的应用场景。本文带你从入门到精通ThreadLocal!
ThreadLocal类用来提供线程内部的局部变量。这种变量在多线程环境下访问(通过get和set方法访问)时能保证各个线程的变量相对独立于其他线程内的变量。ThreadLocal实例通常来说都是private static类型的,用于关联线程和线程上下文。
它一共有四个常用的方法
方法声明 | 描述 |
---|---|
ThreadLocal() | 创建ThreadLocal对象 |
public void set( T value) | 设置当前线程绑定的局部变量 |
public T get() | 获取当前线程绑定的局部变量 |
public void remove() | 移除当前线程绑定的局部变量 |
有人就会问到了,在多线程环境下,想要保证线程同步访问一段资源,用synchronized不也可以做到吗,为什么要用ThreadLocal?或者说使用ThreadLocal有什么好处?
接下来我们来看一个案例:
- public class MyDemo {
- private String content;
-
- private String getContent() {
- return content;
- }
-
- private void setContent(String content) {
- this.content = content;
- }
-
- public static void main(String[] args) {
- MyDemo demo = new MyDemo();
- for (int i = 0; i < 5; i++) {
- Thread thread = new Thread(new Runnable() {
- @Override
- public void run() {
- demo.setContent(Thread.currentThread().getName() + "的数据");
- System.out.println("-----------------------");
- System.out.println(Thread.currentThread().getName() + "--->" + demo.getContent());
- }
- });
- thread.setName("线程" + i);
- thread.start();
- }
- }
- }
-
-
程序很简单,开启5个线程,每个线程都会在run方法中进行set当前线程的资源和get资源
运行结果如下:
线程1—>线程1的数据
线程0—>线程1的数据
线程2—>线程4的数据
线程4—>线程4的数据
线程3—>线程3的数据
我们会发现线程0和线程2访问到了不属于自己的资源,这就会存在并发问题,好的,接下里我们尝试着用synchronized加锁
- public class Demo02 {
-
- private String content;
-
- public String getContent() {
- return content;
- }
-
- public void setContent(String content) {
- this.content = content;
- }
-
- public static void main(String[] args) {
- Demo02 demo02 = new Demo02();
-
- for (int i = 0; i < 5; i++) {
- Thread t = new Thread(){
- @Override
- public void run() {
- synchronized (Demo02.class){
- demo02.setContent(Thread.currentThread().getName() + "的数据");
- System.out.println("-------------------------------------");
- String content = demo02.getContent();
- System.out.println(Thread.currentThread().getName() + "--->" + content);
- }
- }
- };
- t.setName("线程" + i);
- t.start();
- }
- }
- }
-
-
运行结果:
线程0—>线程0的数据
线程3—>线程3的数据
线程4—>线程4的数据
线程2—>线程2的数据
线程1—>线程1的数据
运行结果证明:用synchronized可以解决线程同步安全性问题
接下来用ThreadLocal试试
- public class MyDemo1 {
-
- private static ThreadLocal<String> tl = new ThreadLocal<>();
-
- private String content;
-
- private String getContent() {
- return tl.get();
- }
-
- private void setContent(String content) {
- tl.set(content);
- }
-
- public static void main(String[] args) {
- MyDemo1 demo = new MyDemo1();
- for (int i = 0; i < 5; i++) {
- Thread thread = new Thread(new Runnable() {
- @Override
- public void run() {
- demo.setContent(Thread.currentThread().getName() + "的数据");
- System.out.println("-----------------------");
- System.out.println(Thread.currentThread().getName() + "--->" + demo.getContent());
- }
- });
- thread.setName("线程" + i);
- thread.start();
- }
- }
- }
-
-
运行结果:
线程3—>线程3的数据
线程2—>线程2的数据
线程0—>线程0的数据
线程1—>线程1的数据
线程4—>线程4的数据
同样没问题,但是关键之处在于,我们这里强调的是线程隔离,而不是线程同步的问题,在这种案例中用synchronized显然是不合适的。
ThreadLocal与synchronized的区别
synchronized | ThreadLocal | |
---|---|---|
原理 | 同步机制采用’以时间换空间’的方式, 只提供了一份变量,让不同的线程排队访问 | ThreadLocal采用’以空间换时间’的方式, 为每一个线程都提供了一份变量的副本,从而实现同时访问而相不干扰 |
侧重点 | 多个线程之间访问资源的同步 | 多线程中让每个线程之间的数据相互隔离 |
ThreadLocal内部结构,可以透露的是它的底层采用了ThreadLocalMap这一种Map的存储结构。说到这里,就会有人觉得,在这个Map结构中,key是不是当前线程,而value则存放着局部变量资源呢?JDK早期确实是这样设计的,但是现在不是。
早期设计
如今设计
我们通过图示可以看出,现在的ThreadLocal的设计是:每个Thread维护一个ThreadLocalMap,这个Map的key是ThreadLocal实例本身,value才是真正要存储的值Object。
具体的过程是这样的:
这样设计的好处如下:
- /**
- * 设置当前线程对应的ThreadLocal的值
- *
- * @param value 将要保存在当前线程对应的ThreadLocal的值
- */
- public void set(T value) {
- // 获取当前线程对象
- Thread t = Thread.currentThread();
- // 获取此线程对象中维护的ThreadLocalMap对象
- ThreadLocalMap map = getMap(t);
- // 判断map是否存在
- if (map != null)
- // 存在则调用map.set设置此实体entry
- map.set(this, value);
- else
- // 1)当前线程Thread 不存在ThreadLocalMap对象
- // 2)则调用createMap进行ThreadLocalMap对象的初始化
- // 3)并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中
- createMap(t, value);
- }
-
- /**
- * 获取当前线程Thread对应维护的ThreadLocalMap
- *
- * @param t the current thread 当前线程
- * @return the map 对应维护的ThreadLocalMap
- */
- ThreadLocalMap getMap(Thread t) {
- return t.threadLocals;
- }
- /**
- *创建当前线程Thread对应维护的ThreadLocalMap
- *
- * @param t 当前线程
- * @param firstValue 存放到map中第一个entry的值
- */
- void createMap(Thread t, T firstValue) {
- //这里的this是调用此方法的threadLocal
- t.threadLocals = new ThreadLocalMap(this, firstValue);
- }
-
-
总结就是:set方法,先通过getMap()方法得到当前线程维护的ThreadLocalMap对象,该map对象存在时就将ThreadLocal对象作为key,加上value值在Map中设置成为一个entry;若该map对象不存在时,则调用createMap进行ThreadLocalMap对象的初始化,并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中。
- /**
- * 返回当前线程中保存ThreadLocal的值
- * 如果当前线程没有此ThreadLocal变量,
- * 则它会通过调用{@link #initialValue} 方法进行初始化值
- *
- * @return 返回当前线程对应此ThreadLocal的值
- */
- public T get() {
- // 获取当前线程对象
- Thread t = Thread.currentThread();
- // 获取此线程对象中维护的ThreadLocalMap对象
- ThreadLocalMap map = getMap(t);
- // 如果此map存在
- if (map != null) {
- // 以当前的ThreadLocal 为 key,调用getEntry获取对应的存储实体e
- ThreadLocalMap.Entry e = map.getEntry(this);
- // 对e进行判空
- if (e != null) {
- @SuppressWarnings("unchecked")
- // 获取存储实体 e 对应的 value值
- // 即为我们想要的当前线程对应此ThreadLocal的值
- T result = (T)e.value;
- return result;
- }
- }
- /*
- 初始化 : 有两种情况有执行当前代码
- 第一种情况: map不存在,表示此线程没有维护的ThreadLocalMap对象
- 第二种情况: map存在, 但是没有与当前ThreadLocal关联的entry
- */
- return setInitialValue();
- }
-
- /**
- * 初始化
- *
- * @return the initial value 初始化后的值
- */
- private T setInitialValue() {
- // 调用initialValue获取初始化的值
- // 此方法可以被子类重写, 如果不重写默认返回null
- T value = initialValue();
- // 获取当前线程对象
- Thread t = Thread.currentThread();
- // 获取此线程对象中维护的ThreadLocalMap对象
- ThreadLocalMap map = getMap(t);
- // 判断map是否存在
- if (map != null)
- // 存在则调用map.set设置此实体entry
- map.set(this, value);
- else
- // 1)当前线程Thread 不存在ThreadLocalMap对象
- // 2)则调用createMap进行ThreadLocalMap对象的初始化
- // 3)并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中
- createMap(t, value);
- // 返回设置的值value
- return value;
- }
-
- protected T initialValue() {
- return null;
- }
-
-
总结就是:get方法同样先获取此线程对象中维护的ThreadLocalMap对象,map存在时就以当前ThreadLocal对象作为key通过调用map.getEntry得到对应的entry。entry不为空就直接拿到set的时候存储的value值。如果entry为空,则说明当前线程 1)map不存在,表示此线程没有维护的ThreadLocalMap对象 2)map存在, 但是没有与当前ThreadLocal关联的entry。接下来就要通过调用setInitialValue()方法进行初始化操作
setInitialValue()方法用于建立初始值,如果用户重写了set()方法,则使用它代替set。看源码也会发现它还是先获取当前线程维护的ThreadLocalMap对象,存在则设置key为ThreadLocal对象,value为null的entry实体;不存在则调用createMap进行ThreadLocalMap对象的初始化,也是将key为ThreadLocal对象,value为null作为第一个entry放进ThreadLocalMap中
- /**
- * 删除当前线程中保存的ThreadLocal对应的实体entry
- */
- public void remove() {
- // 获取当前线程对象中维护的ThreadLocalMap对象
- ThreadLocalMap m = getMap(Thread.currentThread());
- // 如果此map存在
- if (m != null)
- // 存在则调用map.remove
- // 以当前ThreadLocal为key删除对应的实体entry
- m.remove(this);
- }
-
-
remove()方法比较简单,直接将当前线程维护的ThreadLocalMap中把以当前ThreadLocal为key删除对应的实体entry
再读ThreadLocalMap源码之前,建议有HashMap的基础,否则读起来比较困难,我的另一篇文章里面有详细介绍HashMap的底层源码分析,链接如下:
ThreadLocalMap并没有实现某个Map接口,而是用独立的方式实现了Map的功能,其内部的Entry也是独立实现。
- /**
- * 初始容量 —— 必须是2的整次幂
- */
- private static final int INITIAL_CAPACITY = 16;
-
- /**
- * 存放数据的table,Entry类的定义在下面分析
- * 同样,数组长度必须是2的整次幂。
- */
- private Entry[] table;
-
- /**
- * 数组里面entrys的个数,可以用于判断table当前使用量是否超过阈值。
- */
- private int size = 0;
-
- /**
- * 进行扩容的阈值,表使用量大于它的时候进行扩容。
- */
- private int threshold; // Default to 0
-
-
-
跟HashMap类似,INITIAL_CAPACITY代表这个Map的初始容量;table 是一个Entry 类型的数组,用于存储数据;size 代表表中的存储数目; threshold 代表需要扩容时对应 size 的阈值。
- /*
- * Entry继承WeakReference,并且用ThreadLocal作为key.
- * 如果key为null(entry.get() == null),意味着key不再被引用,
- * 因此这时候entry也可以从table中清除。
- */
- static class Entry extends WeakReference<ThreadLocal<?>> {
- /** The value associated with this ThreadLocal. */
- Object value;
-
- Entry(ThreadLocal<?> k, Object v) {
- super(k);
- value = v;
- }
- }
-
-
在ThreadLocalMap中,也是用Entry来保存K-V结构数据的。不过Entry中的key只能是ThreadLocal对象,这点在构造方法中已经限定死了。
另外,Entry继承WeakReference,也就是key(ThreadLocal)是弱引用,其目的是将ThreadLocal对象的生命周期和线程生命周期解绑。
答案是:弱引用
在解释为什么用弱引用之前不得不提一个经典ThreadLocal面试问题:ThreadLocal为什么会存在内存泄露问题?
我们最先会想到的是因为弱引用,但实际上并不是
我们先来回顾一下弱引用与强引用的概念:
强引用(“Strong” Reference),就是我们最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还“活着”,垃圾回收器就不会回收这种对象。
弱引用(WeakReference),垃圾回收器一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。
如果使用强引用会怎么样?
结合ThreadLocal的内存图来分析(实线表示强引用,虚线表示弱引用)
假设在业务代码中使用完ThreadLocal ,ThreadLocal Ref被回收了。
但是因为ThreadLocalMap的Entry强引用了ThreadLocal,造成ThreadLocal无法被回收。
在没有手动删除这个Entry以及CurrentThread依然运行的前提下,始终有强引用链 threadRef->currentThread->threadLocalMap->entry,Entry就不会被回收(Entry中包括了ThreadLocal实例和value),导致Entry内存泄漏。
也就是说,ThreadLocalMap中的key使用了强引用, 是无法完全避免内存泄漏的。
如果使用弱引用呢?
结合ThreadLocal的内存图来分析(实线表示强引用,虚线表示弱引用)
同样假设在业务代码中使用完ThreadLocal ,ThreadLocal Ref被回收了。
由于ThreadLocalMap只持有ThreadLocal的弱引用,没有任何强引用指向Threadlocal实例, 所以Threadlocal就可以顺利被gc回收,此时Entry中的key=null。
但是在没有手动删除这个Entry以及CurrentThread依然运行的前提下,也存在有强引用链 ThreadRef->CurrentThread->ThreadLocalMap->entry -> value ,value不会被回收, 而这块value永远不会被访问到了,导致value内存泄漏。
也就是说,ThreadLocalMap中的key使用了弱引用, 也有可能内存泄漏,那么内存泄露的问题就不是使用弱引用和强引用的关系了。
出现内存泄露的真正原因是什么?
细心的同学会发现,在以上两种内存泄漏的情况中,都有两个前提:
1、没有手动删除这个Entry
2、CurrentThread依然运行
第一点很好理解,只要在使用完ThreadLocal,调用其remove方法删除对应的Entry,就能避免内存泄漏。
第二点稍微复杂一点, 由于ThreadLocalMap是Thread的一个属性,被当前线程所引用,所以它的生命周期跟Thread一样长。那么在使用完ThreadLocal之后,如果当前Thread也随之执行结束,ThreadLocalMap自然也会被gc回收,从根源上避免了内存泄漏。
综上,ThreadLocal内存泄漏的根源是:由于ThreadLocalMap的生命周期跟Thread一样长,如果没有手动删除对应key就会导致内存泄漏。
为什么使用弱引用?
根据刚才的分析, 我们知道了: 无论ThreadLocalMap中的key使用哪种类型引用都无法完全避免内存泄漏,跟使用弱引用没有关系。
要避免内存泄漏有两种方式:
相对第一种方式,第二种方式显然更不好控制,特别是使用线程池的时候,线程结束是不会销毁的。
也就是说,只要记得在使用完ThreadLocal及时的调用remove,无论key是强引用还是弱引用都不会有问题。那么为什么key要用弱引用呢?
事实上,在ThreadLocalMap中的set/getEntry方法中,会对key为null(也即是ThreadLocal为null)进行判断,如果为null的话,那么是会对value置为null的。
这就意味着使用完ThreadLocal,CurrentThread依然运行的前提下,就算忘记调用remove方法,弱引用比强引用可以多一层保障:弱引用的ThreadLocal会被回收,对应的value在下一次ThreadLocalMap调用set,get,remove中的任一方法的时候会被清除,从而避免内存泄漏。
来看看我们ThreadLocalMap的构造函数
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue)
- ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
- table = new Entry[INITIAL_CAPACITY]; //初始化大小为16
- int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
- table[i] = new Entry(firstKey, firstValue);
- size = 1;
- setThreshold(INITIAL_CAPACITY);
- }
- //设置调整大小阈值以保持最坏的 2/3 负载因子
- private void setThreshold(int len) {
- threshold = len * 2 / 3;
- }
-
- INITIAL_CAPACITY:是ThreadLocalMap的初始化大小,为16
-
从构造函数我们可以得出结论,ThreadLocalMap的初始大小是16
加载因子由setThreadshold设置阈值大小的时候可以看出,是2/3
ThreadLocal底层的Hash算法就是ThreadLocalMap构造函数中的这一段代码
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1)
(一)先来看firstKey.threadLocalHashCode
- private final int threadLocalHashCode = nextHashCode();
-
- private static int nextHashCode() {
- return nextHashCode.getAndAdd(HASH_INCREMENT);
- }
- //AtomicInteger是一个提供原子操作的Integer类,通过线程安全的方式操作加减,适合高并发情况下的使用
- private static AtomicInteger nextHashCode = new AtomicInteger();
- //特殊的hash值
- private static final int HASH_INCREMENT = 0x61c88647;
-
-
这里定义了一个AtomicInteger类型,每次获取当前值并加上HASH_INCREMENT,HASH_INCREMENT = 0x61c88647,这个值跟斐波那契数列(黄金分割数)有关,其主要目的就是为了让哈希码能均匀的分布在2的n次方的数组里, 也就是Entry[] table中,这样做可以尽量避免hash冲突。
(二)再看& (INITIAL_CAPACITY - 1)
计算hash的时候里面采用了hashCode & (size - 1)的算法,这相当于取模运算hashCode % size的一个更高效的实现。正是因为这种算法,我们要求size必须是2的整次幂,这也能保证在索引不越界的前提下,使得hash发生冲突的次数减小。
Hash冲突我们知道,是在存放entry的时候,通过hash计算得到的数组索引值,在投放到数组中的时候发现已经有元素存在了,那么就会产生hash冲突。
ThreadLocal解决Hash冲突的办法是线性探测法
我们接下来通过ThreadLocalMap中的set方法展示一下线性探测法是怎么运作的
ThreadLocalMap中的set方法
- private void set(ThreadLocal<?> key, Object value) {
- ThreadLocal.ThreadLocalMap.Entry[] tab = table;
- int len = tab.length;
- //计算索引(重点代码,刚才分析过了)
- int i = key.threadLocalHashCode & (len-1);
- /**
- * 使用线性探测法查找元素(重点代码)
- */
- for (ThreadLocal.ThreadLocalMap.Entry e = tab[i];
- e != null;
- e = tab[i = nextIndex(i, len)]) {
- ThreadLocal<?> k = e.get();
- //ThreadLocal 对应的 key 存在,直接覆盖之前的值
- if (k == key) {
- e.value = value;
- return;
- }
- // key为 null,但是值不为 null,说明之前的 ThreadLocal 对象已经被回收了,
- // 当前数组中的 Entry 是一个陈旧(stale)的元素
- if (k == null) {
- //用新元素替换陈旧的元素,这个方法进行了不少的垃圾清理动作,防止内存泄漏
- replaceStaleEntry(key, value, i);
- return;
- }
- }
-
- //ThreadLocal对应的key不存在并且没有找到陈旧的元素,则在空元素的位置创建一个新的Entry。
- tab[i] = new Entry(key, value);
- int sz = ++size;
- /**
- * cleanSomeSlots用于清除那些e.get()==null的元素,
- * 这种数据key关联的对象已经被回收,所以这个Entry(table[index])可以被置null。
- * 如果没有清除任何entry,并且当前使用量达到了负载因子所定义(长度的2/3),那么进行 * rehash(执行一次全表的扫描清理工作)
- */
- if (!cleanSomeSlots(i, sz) && sz >= threshold)
- rehash();
- }
-
- /**
- * 获取环形数组的下一个索引
- */
- private static int nextIndex(int i, int len) {
- return ((i + 1 < len) ? i + 1 : 0);
- }
-
-
-
代码执行流程:
A. 首先还是根据key计算出索引 i,然后查找i位置上的Entry,
B. 若是Entry已经存在并且key等于传入的key,那么这时候直接给这个Entry赋新的value值,
C. 若是Entry存在,但是key为null,则调用replaceStaleEntry来更换这个key为空的Entry,
D. 不断循环检测,直到遇到为null的地方,这时候要是还没在循环过程中return,那么就在这个null的位置新建一个Entry,并且插入,同时size增加1。
E. 最后调用cleanSomeSlots,清理key为null的Entry,最后返回是否清理了Entry,接下来再判断sz 是否>= thresgold达到了rehash的条件,达到的话就会调用rehash函数执行一次全表的扫描清理
重点分析:ThreadLocalMap使用线性探测法来解决哈希冲突的。
该方法一次探测下一个地址,直到有空的地址后插入,若整个空间都找不到空余的地址,则产生溢出。
举个例子,假设当前table长度为16,也就是说如果计算出来key的hash值为14,如果table[14]上已经有值,并且其key与当前key不一致,那么就发生了hash冲突,这个时候将14加1得到15,取table[15]进行判断,这个时候如果还是冲突会回到0,取table[0],以此类推,直到可以插入。
按照上面的描述,可以把Entry[] table看成一个环形数组。
在上面的set方法中,在最后会判断当前下标往后的元素是否存在需要value回收的,如果不存在需要回收并且当前总元素大于等于阈值,那么就会调用rehash()扩容。
rehash()源码
- /**
- *重新包装和/或重新调整桌子的大小。首先扫描整个表删除过时的条目。
- *如果这不能充分缩小表格的大小,请将表格大小加倍
- */
- private void rehash() {
- expungeStaleEntries(); //清除表中所有过时的条目
-
- // Use lower threshold for doubling to avoid hysteresis
- if (size >= threshold - threshold / 4)
- resize(); //扩容
- }
-
扩容之前还会再重新对key已经被GC了的元素进行回收,回收后如果总数还是大于等于阈值的3/4,那么就会调用resize()进行真正的扩容。
核心扩容resize()
- private void resize() {
- Entry[] oldTab = table;
- int oldLen = oldTab.length;
- int newLen = oldLen * 2; //扩容到原来的2倍
- Entry[] newTab = new Entry[newLen];
- int count = 0;
-
- for (int j = 0; j < oldLen; ++j) {
- Entry e = oldTab[j];
- if (e != null) {
- ThreadLocal<?> k = e.get();
- if (k == null) {
- e.value = null; // Help the GC
- } else {
- int h = k.threadLocalHashCode & (newLen - 1);
- while (newTab[h] != null)
- h = nextIndex(h, newLen);
- newTab[h] = e;
- count++;
- }
- }
- }
-
- setThreshold(newLen);
- size = count;
- table = newTab;
- }
-
可以看到newLen的长度是原来长度的2倍,也就代表着扩容到原来的2倍大小,并且所有的元素还会重新计算一次hash操作,阈值也会更新。
Web系统Session的存储就是ThreadLocal一个典型的应用场景。
Web容器采用线程隔离的多线程模型,也就是每一个请求都会对应一条线程,线程之间相互隔离,没有共享数据。这样能够简化编程模型,程序员可以用单线程的思维开发这种多线程应用。
当请求到来时,可以将当前Session信息存储在ThreadLocal中,在请求处理过程中可以随时使用Session信息,每个请求之间的Session信息互不影响。当请求处理完成后通过remove方法将当前Session信息清除即可。