ThreadLocal : 没有共享，就没有伤害
ThreadLocal 的工作原理
在解释 ThreadLocal 的工作原理之前， 你先自己想想：如果让你来实现 ThreadLocal 的功能，你会怎么设计呢？ThreadLocal 的目标是让不同的线程有不同的变量 V，那最直接的方法就是创建一个 Map，它的 Key 是线程，Value 是每个线程拥有的变量 V，ThreadLocal 内部持有这样的一个 Map 就可以了。你可以参考下面的示意图和示例代码来理解。
class MyThreadLocal<T> {
Map<Thread, T> locals =
new ConcurrentHashMap<>();
//获取线程变量
T get() {
return locals.get(
Thread.currentThread());
}
//设置线程变量
void set(T t) {
locals.put(
Thread.currentThread(), t);
}
}
那 Java 的 ThreadLocal 是这么实现的吗？这一次我们的设计思路和 Java 的实现差异很大!
Java 的实现里面也有一个 Map，叫做 ThreadLocalMap，不过持有 ThreadLocalMap 的不是 ThreadLocal，而是 Thread。Thread 这个类内部有一个私有属性 threadLocals，其类型就是 ThreadLocalMap，ThreadLocalMap 的 Key 是 ThreadLocal。你可以结合下面的示意图和精简之后的 Java 实现代码来理解。
class Thread {
//内部持有ThreadLocalMap
ThreadLocal.ThreadLocalMap
threadLocals;
}
class ThreadLocal<T>{
public T get() {
//首先获取线程持有的
//ThreadLocalMap
ThreadLocalMap map =
Thread.currentThread()
.threadLocals;
//在ThreadLocalMap中
//查找变量
Entry e =
map.getEntry(this);
return e.value;
}
static class ThreadLocalMap{
//内部是数组而不是Map
Entry[] table;
//根据ThreadLocal查找Entry
Entry getEntry(ThreadLocal key){
//省略查找逻辑
}
//Entry定义
static class Entry extends
WeakReference<ThreadLocal>{
Object value;
}
}
}
初看上去，我们的设计方案和 Java 的实现仅仅是 Map 的持有方不同而已，我们的设计里面 Map 属于 ThreadLocal，而 Java 的实现里面 ThreadLocalMap 则是属于 Thread。这两种方式哪种更合理呢？很显然 Java 的实现更合理一些。在 Java 的实现方案里面，ThreadLocal 仅仅是一个代理工具类，内部并不持有任何与线程相关的数据，所有和线程相关的数据都存储在 Thread 里面，这样的设计容易理解。而从数据的亲缘性上来讲，ThreadLocalMap 属于 Thread 也更加合理。
当然还有一个更加深层次的原因，那就是不容易产生内存泄露。
在我们的设计方案中，ThreadLocal 持有的 Map 会持有 Thread 对象的引用，这就意味着，只要 ThreadLocal 对象存在，那么 Map 中的 Thread 对象就永远不会被回收。ThreadLocal 的生命周期往往都比线程要长，所以这种设计方案很容易导致内存泄露。而 Java 的实现中 Thread 持有 ThreadLocalMap，而且 ThreadLocalMap 里对 ThreadLocal 的引用还是弱引用（WeakReference），所以只要 Thread 对象可以被回收，那么 ThreadLocalMap 就能被回收。Java 的这种实现方案虽然看上去复杂一些，但是更加安全。
Java 的 ThreadLocal 实现应该称得上深思熟虑了，不过即便如此深思熟虑，还是不能百分百地让程序员避免内存泄露，例如在线程池中使用 ThreadLocal，如果不谨慎就可能导致内存泄露。
ThreadLocal 与内存泄露
在线程池中使用 ThreadLocal 为什么可能导致内存泄露呢？原因就出在线程池中线程的存活时间太长，往往都是和程序同生共死的，这就意味着 Thread 持有的 ThreadLocalMap 一直都不会被回收，再加上 ThreadLocalMap 中的 Entry 对 ThreadLocal 是弱引用（WeakReference），所以只要 ThreadLocal 结束了自己的生命周期是可以被回收掉的。但是 Entry 中的 Value 却是被 Entry 强引用的，所以即便 Value 的生命周期结束了，Value 也是无法被回收的，从而导致内存泄露。
那在线程池中，我们该如何正确使用 ThreadLocal 呢？其实很简单，既然 JVM 不能做到自动释放对 Value 的强引用，那我们手动释放就可以了。如何能做到手动释放呢？估计你马上想到 try{}finally{}方案了，这个简直就是手动释放资源的利器。示例的代码如下，你可以参考学习。
ExecutorService es;
ThreadLocal tl;
es.execute(()->{
//ThreadLocal增加变量
tl.set(obj);
try {
// 省略业务逻辑代码
}finally {
//手动清理ThreadLocal
tl.remove();
}
});
InheritableThreadLocal 与继承性
通过 ThreadLocal 创建的线程变量，其子线程是无法继承的。也就是说你在线程中通过 ThreadLocal 创建了线程变量 V，而后该线程创建了子线程，你在子线程中是无法通过 ThreadLocal 来访问父线程的线程变量 V 的。
如果你需要子线程继承父线程的线程变量，那该怎么办呢？其实很简单，Java 提供了 InheritableThreadLocal 来支持这种特性，InheritableThreadLocal 是 ThreadLocal 子类，所以用法和 ThreadLocal 相同，这里就不多介绍了。
不过，我完全不建议你在线程池中使用 InheritableThreadLocal，不仅仅是因为它具有 ThreadLocal 相同的缺点——可能导致内存泄露，
线程池中线程的创建是动态的，很容易导致继承关系错乱，如果你的业务逻辑依赖 InheritableThreadLocal，那么很可能导致业务逻辑计算错误，而这个错误往往比内存泄露更要命。
每一个线程都有一个私有变量，是ThreadLocalMap类型。当为线程添加ThreadLocal对象时，就是保存到这个map中，所以线程与线程间不会互相干扰。总结起来，一句话：我有我的young，哦，不对，是我有我的map。弄清楚了这些，是不是使用的时候就自信了很多。但是，这是不是就意味着可以大胆的去使用了呢？其实，不尽然，有一个“大坑”在等着你。
那个“大坑”指的就是因为ThreadLocal使用不当，会引发内存泄露的问题。笔者给出两段示例代码，来说明这个问题。
无处不在的ThreadLocalMap
还是老规矩，先来看看类上的注释，翻译过来就是这么几点：
-
ThreadLocalMap是一个自定义的hash map，专门用来保存线程的thread local变量
-
它的操作仅限于ThreadLocal类中，不对外暴露
-
这个类被用在Thread类的私有变量threadLocals和inheritableThreadLocals上
-
为了能够保存大量且存活时间较长的threadLocal实例，hash table entries采用了WeakReferences作为key的类型
-
一旦hash table运行空间不足时，key为null的entry就会被清理掉
static class ThreadLocalMap {
// hash map中的entry继承自弱引用WeakReference，指向threadLocal对象
// 对于key为null的entry，说明不再需要访问，会从table表中清理掉
// 这种entry被成为“stale entries”
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
/**
* The initial capacity -- MUST be a power of two.
*/
private static final int INITIAL_CAPACITY = 16;
/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
/**
* The number of entries in the table.
*/
private int size = 0;
/**
* The next size value at which to resize.
*/
private int threshold; // Default to 0
/**
* Set the resize threshold to maintain at worst a 2/3 load factor.
*/
private void setThreshold(int len) {
threshold = len * 2 / 3;
}
/**
* Increment i modulo len.
*/
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
/**
* Decrement i modulo len.
*/
private static int prevIndex(int i, int len) {
return ((i - 1 >= 0) ? i - 1 : len - 1);
}
/**
* Construct a new map initially containing (firstKey, firstValue).
* ThreadLocalMaps are constructed lazily, so we only create
* one when we have at least one entry to put in it.
*/
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
}
当创建一个ThreadLocalMap时，实际上内部是构建了一个Entry类型的数组，初始化大小为16，阈值threshold为数组长度的2/3，Entry类型为WeakReference，有一个弱引用指向ThreadLocal对象。
为什么Entry采用WeakReference类型？
认识WeakReference类
WeakReference继承Reference，其中只有两个构造函数：
public class WeakReference<T> extends Reference<T> {
public WeakReference(T referent) {
super(referent);
}
public WeakReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q);
}
}
- WeakReference(T referent)：referent就是被弱引用的对象（注意区分弱引用对象和被弱引用的对应，弱引用对象是指WeakReference的实例或者其子类的实例），比如有一个Apple实例apple，可以如下使用，并且通过get()方法来获取apple引用。也可以再创建一个继承WeakReference的类来对Apple进行弱引用，下面就会使用这种方式。
WeakReference<Apple> appleWeakReference = new WeakReference<>(apple);
Apple apple2 = appleWeakReference.get();
- WeakReference(T referent, ReferenceQueue<? super T> q)：与上面的构造方法比较，多了个ReferenceQueue，在对象被回收后，会把弱引用对象，也就是WeakReference对象或者其子类的对象，放入队列ReferenceQueue中，注意不是被弱引用的对象，被弱引用的对象已经被回收了。
Java垃圾回收时，看一个对象需不需要回收，就是看这个对象是否可达。什么是可达，就是能不能通过引用去访问到这个对象。(当然，垃圾回收的策略远比这个复杂，这里为了便于理解，简单给大家说一下)。
jdk1.2以后，引用就被分为四种类型：强引用、弱引用、软引用和虚引用。强引用就是我们常用的Object obj = new Object()，obj就是一个强引用，指向了对象内存空间。当内存空间不足时，Java垃圾回收程序发现对象有一个强引用，宁愿抛出OutofMemory错误，也不会去回收一个强引用的内存空间。而弱引用，即WeakReference，意思就是当一个对象只有弱引用指向它时，垃圾回收器不管当前内存是否足够，都会进行回收。反过来说，这个对象是否要被垃圾回收掉，取决于是否有强引用指向。ThreadLocalMap这么做，是不想因为自己存储了ThreadLocal对象，而影响到它的垃圾回收，而是把这个主动权完全交给了调用方，一旦调用方不想使用，设置ThreadLocal对象为null，内存就可以被回收掉。
内存溢出问题解答
至此，该做的铺垫都已经完成了，此时，我们可以来看看上面那个内存泄漏的例子。示例中执行一次for循环里的代码后，对应的内存状态：
循环一次内存状态
-
t为创建TestClass对象返回的引用，临时变量，在一次for循环后就执行出栈了
-
thread为创建Thread对象返回的引用，run方法在执行过程中，暂时不会执行出栈
调用t=null后，虽然无法再通过t访问内存地址，但是当前线程依旧存活，可以通过thread指向的内存地址，访问到Thread对象，从而访问到ThreadLocalMap对象，访问到value指向的内存空间，访问到arr指向的内存空间，从而导致Java垃圾回收并不会回收int[1000000]@541这一片空间。那么随着循环多次之后，不被回收的堆空间越来越大，最后抛出java.lang.OutOfMemoryError: Java heap space。
您问：那为什么调用t.threadLocal.remove()就可以呢？
我答：这就得看remove方法里究竟做了什么了，请看：
是不是恍然大悟？来看下调用remove方法之后的内存状态
：
因为remove方法将referent和value都被设置为null，所以ThreadLocal@540和Memory$TestClass@538对应的内存地址都变成不可达，Java垃圾回收自然就会回收这片内存，从而不会出现内存泄漏的错误。
ThreadLocalMap之番外篇
笔者之前写过关于TreeMap和HashMap的文章，凡是Map的实现，都有自己降低哈希冲突和解决哈希冲突的方法。在这里，ThreadLocalMap是如何处理的呢？请往下看。
如何降低哈希冲突
回顾ThreadLocalMap添加元素的源码：
-
方式一：构造方法
-
方式二：set方法
其中i就是ThreadLocal在ThreadLocalMap中存放的索引，计算方式为：key.threadLocalHashCode & (len-1)。我们先来看threadLocalHashCode是什么？
private final int threadLocalHashCode = nextHashCode();
也就是说，每一个ThreadLocal都会根据nextHashCode生成一个int值，作为哈希值，然后根据这个哈希值&(数组长度-1)，从而获取到哈希值的低N位(以len为16，16-1保证低四位都是1，从而获取哈希值本身的低四位值)，从而获取到在数组中的索引位置。那它是如何降低哈希冲突的呢？玄机就在于这个nextHashCode方法。
private static AtomicInteger nextHashCode = new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
0x61c88647是什么？转化为十进制是1640531527。2654435769转换成int类型就是-1640531527。2654435769等于(根号5-1)/2乘以2的32次方。(根号5-1)/2是什么？是黄金分割数，近似为0.618。也就是说0x61c88647理解为一个黄金分割数乘以2的32次方。有什么好处？它可以神奇的保证nextHashCode生成的哈希值，均匀的分布在2的幂次方上，且小于2的32次方。来看例子：
public class ThreadLocalHashCodeTest {
private static AtomicInteger nextHashCode = new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
public static void main(String[] args) {
for (int i = 0; i < 16; i++) {
System.out.print(nextHashCode() & 15);
System.out.print(" ");
}
System.out.println();
for (int i = 0; i < 32; i++) {
System.out.print(nextHashCode() & 31);
System.out.print(" ");
}
System.out.println();
for (int i = 0; i < 64; i++) {
System.out.print(nextHashCode() & 63);
System.out.print(" ");
}
}
}
输出结果：
看见没有，元素索引值完美的散列在数组当中，并没有出现冲突。
如何解决哈希冲突
ThreadLocalMap采用黄金分割数的方式，大大降低了哈希冲突的情况，但是这种情况还是存在的，那如果出现，它是怎么解决的呢？请看：
private void set(ThreadLocal<?> key, Object value) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
// 出现哈希冲突
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
// 如果是同一个对象，则覆盖value值
if (k == key) {
e.value = value;
return;
}
// 如果key为null，则替换它的位置
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
// 否则往后一个位置找，直到找到空的位置
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
当出现哈希冲突时，它的做法看是否是同一个对象或者是是否可以替换，否则往后移动一位，继续判断。
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
扩容
通过set方法里的代码，我们知道ThreadLocalMap扩容有两个前提：
-
!cleanSomeSlots(i, sz)
-
size >= threshold
元素个数大于阈值进行扩容，这个很好理解，那么还有一个前提是什么意思呢？我们来看cleanSomeSlots()做了什么：
private boolean cleanSomeSlots(int i, int n) {
boolean removed = false;
Entry[] tab = table;
int len = tab.length;
do {
i = nextIndex(i, len);
Entry e = tab[i];
if (e != null && e.get() == null) {
n = len;
removed = true;
i = expungeStaleEntry(i);
}
} while ( (n >>>= 1) != 0);
return removed;
}
方法上注释写的很明白，从当前插入元素位置，往后扫描数组中的元素，判断是否是“stale entry”。在前面将ThreadLocalMap类声明信息的时候讲过，“stale entry”表示的是那些key为null的entry。cleanSomeSlots方法就是找到他们，调用expungeStaleEntry方法进行清理。如果找到，则返回true，否则返回false。
您问：为什么扩容要看它的返回值呢？
我答：因为一旦找到，就调用expungeStaleEntry方法进行清理。
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
看到没有，size会减一，那么添加元素导致size加1，cleanSomeSlots一旦找到，则会清理一个或者多个元素，size减去的最少为1，所以返回true，自然就没有必要再判断size是否大于等于阈值了。
好了，前提条件一旦满足，则调用rehash方法，此时还未扩容：
private void rehash() {
expungeStaleEntries();
// Use lower threshold for doubling to avoid hysteresis
if (size >= threshold - threshold / 4)
resize();
}
哈哈，这里才是真正的扩容，要进行扩容：
-
当前插入元素的位置，往后没有需要清理的stale entry
-
size大于等于阈值
-
清理掉stale entry之后，size大于等于3/4阈值
既然搞清楚了条件，那么满足后，又是如何扩容的呢？
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
int newLen = oldLen * 2;
// 新建一个数组，按照2倍长度扩容
Entry[] newTab = new Entry[newLen];
int count = 0;
for (Entry e : oldTab) {
if (e != null) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null; // Help the GC
} else {
// key不为null，重新计算索引位置
int h = k.threadLocalHashCode & (newLen - 1);
while (newTab[h] != null)
h = nextIndex(h, newLen);
// 插入新的数组中索引位置
newTab[h] = e;
count++;
}
}
}
setThreshold(newLen);
size = count;
table = newTab;
}
两倍长度扩容，重新计算索引，扩容的同时也顺便清理了key为null的元素，即stale entry，不再存入扩容后的数组中。
补充
不知您有没有注意到，ThreadLocalMap中出现哈希冲突时，它是线性探测，直到找到空的位置。这种效率是非常低的，那为什么Java大神们写代码时还要这么做呢？
笔者认为取决于它采用的哈希算法，正因为nextHashCode()，保证了冲突出现的可能性很低。而且ThreadLocalMap在处理过程中非常注意清理”stale entry”，及时释放出空余位置，从而降低了线性探测带来的低效。
浙公网安备 33010602011771号