详解Java ThreadLocal

个人博客

详解Java ThreadLocal | iwts’s blog

Java ThreadLocal

ThreadLocal提供了线程内存储变量的能力，这些变量不同之处在于每一个线程读取的变量是对应的互相独立的。通过get和set方法就可以得到当前线程对应的值。

TreadLocal存储模型

ThreadLocal的静态内部类ThreadLocalMap为每个Thread都维护了一个数组table，ThreadLocal确定了一个数组下标，而这个下标就是value存储的对应位置。
这样看太抽象了，具体数据结构可以从存储方法开始看。

根据set方法探究ThreadLocal存储模型

看上去简单粗暴，先是获取线程，然后看能不能获取数据结构，能获取就直接set，获取不到就初始化。

那么这里指向了一个核心方法：ThreadLocalMap是怎么获得的。

这个东西竟然是存储在线程对象里面的：

等于说TreadLocal的核心内部类，是存在一个线程中的。
这个时候再回过头来看ThreadLocalMap：

这个Entry继承了WeakReference，代表他是一个弱引用，而其泛型则是ThreadLocal，那么说明了单个Entry节点，底层是一个kv结构，key是ThreadLocal的弱引用，value是一个Object。

但是这个只是Entry节点，ThreadLocalMap的底层并不是KV结构，而是一个Entry数组。

这里再继续看set()方法是怎么处理的：

可以看出来，Entry的key就是这个具体的ThreadLocal对象，value是具体设置的value。

那么这个下标怎么计算的？

这里与计算比较类似HashMap，保证数组长度是2的幂，这样与运算直接就是取模了，具体内容参考下面。

综上，可以得到ThreadLocal究竟是怎么存的：

注意，key存储的是ThreadLocal的弱引用，那么扩展到JVM内存模型下：

ThreadLocal本身的引用是正常放在栈中的，但是由于WeakReference，所以key对ThreadLocal的引用是虚引用。这也是OOM的主要原因。

Thread中threadLocals

整个ThreadLocal的数据都是维护在单个线程的属性中，所以保证了线程间的隔离，因为这玩意就是线程自己的一个变量。

ThreadLocalMap

ThreadLocal的内部类，其中定义了Entry节点，存储具体的数据。而本身提供了Entry数组，用于存储线程下全部的ThreadLocal数据。

此外提供了一系列数组操作方法，以及扩容等操作。

Entry

内部类Entry，继承了WeakReference，其内部设置属性value，实现了一个类似KV结构的数据结构，保证了key是ThreadLocal的一个弱引用，value是具体的数值。

ThreadLocalMap的维护

getMap()

等于从线程中获取线程本身的ThreadLocalMap对象。

ThreadLocalMap的初始化

java.lang.ThreadLocal#createMap

直接走了构造方法：

初始化了Entry数组。初始化数组长度为16，并且设置了扩容阈值threshold。具体看下面。

扩容机制

类似HashMap扩容，初始化长度为16，后续扩容的时候直接*2，保证长度是2的幂。只有在超过阈值的时候才会扩容。

阈值threshold的维护，为当前数组长度的2/3。

跟HashMap一样，扩容后需要对旧值重新hash，定位到确定的下标。相比HashMap简单多了。

ThreadLocal对象hash定位下标

算法看起来还是比较简单的。了解HashMap这里没啥难度，由于长度必然是2的幂，这样与计算也是和取模的效果是一样的。

主要是这个threadLocalHashCode是什么。

这里算是一个小优化了，主要获取方法：

这里走CAS执行一次自增，增量为常量0x61c88647。

这样，0x61c88647是斐波那契散列乘数，那么后续的自增导致hash出来的结果分布会比较均匀，可以很大程度上避免hash冲突，下面是15次操作获取的hash值

hash冲突

由于ThreadLocalMap的底层是一个数组，设计上也不想太复杂，所以没有采用HashMap的拉链法，而是采用线性探测来解决hash冲突。

非常简单，其实就是+1，看是否越界，越界设置0。其实这里改成取模更加简洁。

ThreadLocal弱引用与内存泄漏

回到最上面Entry的设计，继承了WeakReference，表明了key的对象是个弱引用。

那么在ThreadLocal执行完毕后，如果没有及时清除，就会导致ThreadLocal对象没有具体的引用对象。那么就会被GC回收掉。

参考上面的图，GC回收的是堆，堆中的这个key，他引用的是ThreadLocal，也就是说这个key的引用，是会被GC回收掉的。

而Entry中value是个普通的Object，那么value本身是不会被回收的。
这样在大量操作后，就会导致value无法回收，导致内存泄漏。

解决方案

ThreadLocal使用结束后及时remove()。

而JDK为了解决这个问题，本身也或多或少在帮助我们回收。

remove()的时候会主动触发，而get()、set()在执行的时候也会间接执行：expungeStaleEntry()方法。

这个方法会主动清除所有Entry中key为null的对象。

强引用解决方案

比较奇葩，感觉用的不多。

即利用static修饰ThreadLocal，这样就能保证ThreadLocal对象是强引用，从根本上解决问题。

为什么选择用弱引用

依然是OOM问题。

由于ThreadLocalMap的生命周期跟Thread一样长，如果是强引用，那么手动删除对应key的情况下，仍然会导致内存泄漏。

但是使用弱引用可以多一层保障：弱引用ThreadLocal被清理后key为null，对应的value在下一次ThreadLocalMap调用set、get、remove的时候可能会被清除。

弱引用虽然会导致OOM，但是强引用不仅会导致OOM，还会更多。

ThreadLocal API

都比较简单感觉没什么好聊的。

需要注意的是hash冲突问题，由于hash冲突的解决方案是线性探测，所以在get的时候，需要对比key是否一致，如果不一致可能是hash冲突，需要利用线性探测，循环遍历一轮数组。