深入理解ThreadLocal
存储结构
threadLocal存储于Thread类上的ThreadLocalMap类型的threadLocals中。
从ThreadLocalMap的名字上可以看出其结构类似于HashMap，它也是使用key-value结构的Entry数组table来存储ThreadLocal和值。
但区别在于Entry继承于WeakReference，key使用弱引用，其好处在于当threadlocal没有强引用时，key将在下一次gc中被回收，但仅仅key被回收，value不会被回收，这就是ThreadLocal会导致内存泄漏的原因，但ThreadLocal也有一些机制去处理这种情况，后续会说。
还有一种区别在于解决hash冲突的方式，HashMap是使用数组+链表，即拉链法来解决的，而ThreadLocalMap使用线性探测法，即当前位置冲突，探测下一个地址是否冲突，不冲突插入。
set过程
首先是获取thread上的ThreadLocalMap
public void set(T value) {
//1.获取当前线程
Thread t = Thread.currentThread();
//2.获取线程上的ThreadLocalMap
ThreadLocalMap map = getMap(t);
if (map != null)
//3.1.存在调用ThreadLocalMap的set方法
map.set(this, value);
else
//3.2.不存在初始化ThreadLocalMap
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
获取到ThreadLocalMap之后，将threadlocal和value封装为Entry保存到数组中。
private void set(ThreadLocal<?> key, Object value) {
Entry[] tab = table;
int len = tab.length;
//1.通过threadlocal的threadLocalHashCode获取到存放位置
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
//2.1.当前存放位置key相等，替换值
if (k == key) {
e.value = value;
return;
}
//2.2.当前存放位置key已经被gc回收，替换当前位置的entry
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
//2.3.当前位置已存放别的threadlocal，线性探测下一个位置
}
//3.当前位置为空，存放
tab[i] = new Entry(key, value);
int sz = ++size;
//4.回收key已经gc的entry，然后判断是否扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
我们看下threadLocalHashCode的获取。
private final int threadLocalHashCode = nextHashCode();
private static AtomicInteger nextHashCode =
new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
每次实例化ThreadLocal的时候都会从nextHashCode获取，而每次获取都会加上`0x61c88647，HASH_INCREMENT的注释是比起连续的自增序列能使threadlocal在ThreadLocalMap分布更加均匀。
for (int i = 0; i < 16; i++) {
System.out.println(0x61c88647 * i & 15);
}
运行这段代码，我们确实可以发现16个值随机均匀的分布在0-15之间，正好符合threadlocalMap上面的16个entry大小数组。
我们知道threadLocalMap在到达threshold的时候会发生扩容，这时ThreadLocal会进行rehash重新存放，我们将上面的i改为32会发现还是均匀的分布在0-32之间，那么一直不会发生hash冲突。那么到底什么时候会发生hash冲突？
前面我们提到Entry的key为弱引用，在没有强引用下，下次gc将会回收，在set方法中我们可以看replaceStaleEntry和cleanSomeSlots方法，这里就是回收key被回收后的Entry节点。
我们先说回hash冲突，假设在size达到threshold之前，有些key已经被回收，那么在新建了16个threadlocal之后，将出现一个再次填充到第一个threadlocal位置的threadlocal，这时就会导致hash冲突。
我们假设ThreadLocalMap大小为4，阈值为4，如下图所示：
ThreadLocalMap填入ThreadLocal4时，ThreadLocal2、ThreadLocal3已经没有强引用触发gc，那么Entry2、Entry3的key将会为null。
这时将会触发cleanSomeSlots，回收Entry2、Entry3。
这时我们才填入ThreadLocal5，这时就会和Entry1发生hash冲突，探测下一个位置填入。
以上就是整个set过程中hash冲突发生的情况和ThreadLocalMap如何处理的过程。
下面我们再看下replaceStaleEntry和cleanSomeSlots如何回收Entry的。
我们追踪replaceStaleEntry和cleanSomeSlots会发现其都调用expungeStaleEntry方法。
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
//释放当前位置的过期Entry
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
Entry e;
int i;
//从当前位置开始探测下一个，如果已经过期则清除，如果未过期重新rehash插入。
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
//已经gc清除Entry
e.value = null;
tab[i] = null;
size--;
} else {
//Threadlocal还没被gc，进行rehash
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
这个清除过期Entry的逻辑，我们可以看到在get和remove等方法中进行了调用，这也是ThreadLocal解决内存泄漏的机制。
总结
- ThreadLocal使用类似HashMap的结构进行存储，区别在于其key使用弱引用，还有解决hash冲突使用线性探测法。
- ThreadLocal发生hash冲突的情况，只在ThreadLocalMap达到阈值之前已经发生弱引用被gc的情况下，否则ThreadLocalMap只会进行扩容，极少发生hash冲突。
- ThreadLocal解决因为弱引用被gc导致Entry节点还存在的内存泄漏，使用在set、get、remove等方法中进行回收弱引用被gc的Entry节点。因此唯一存在内存泄漏的情况是在弱引用被gc之后从未调过set、get、remove等方法，对此阿里规范中要求，对不在使用ThreadLocal要调用remove方法。
子线程继承父线程的ThreadLocal——InheritableThreadLocal
InheritableThreadLocal会让子线程拥有父线程的InheritableThreadLocal，其原理就在于Thread在创建的时候会获取当前线程的inheritableThreadLocals，然后使用创建自己的inheritableThreadLocals会将当前的inheritableThreadLocals复制。
Netty对ThreadLocal的优化——FastThreadLocal
存储结构
FastThreadLocal对应的map为InternalThreadLocalMap，他抛弃了ThreadLocalMap的结构，使用Object数组进行存储。
其中头部存放的是Set集合的FastThreadLocal，而其他部分存放的是FastThreadLocal的值。FastThreadLocal上有一个index变量存放其值在Object数组中的位置。
而FastThreadLocal index的值是全局自增的。
优化点
set仅仅只需要将FastThreadLocal的值存放到Object上对应的位置，同时将FastThreadLocal存放到Object头部的set集合中
get操作也只需要拿到FastThreadLocal的index，去object上获取值
remove操作也只需要拿到FastThreadLocal的index，将object对应的值置为unset，同时从object头部的set集合移除FastThreadLocal。
这样一来不需要处理hash冲突和清除过期的节点，但由于index是一直自增的，会导致Object上无效的位置无法重复使用，Object一直增大，相当于用空间换时间。
还有FastThreadLocal的内存泄漏问题解决在于同样需要手动调用FastThreadLocal的remove方法，当Netty提供更方便的操作，使用FastThreadLocalRunnable对Runnable进行封装，其在run方法中调用FastThreadLocal的removeAll方法进行清除。
ThreadLocal在线程池中使用的问题
ThreadLocal销毁问题
由于线程池中的线程在使用完，不会进行销毁，只是重新放入线程池中，如果线程在使用完不对ThreadLocal进行remove，那么这会导致下次使用这个线程时获取到上次使用的ThreadLocal。
Spring中大量使用ThreadLocal，例如RequestContextHolder使用THreadLocal存放Request和Respons，Spring对它处理就是使用RequestContextFilter在逻辑处理完成之后调用remove方法。
ThreadLocal传输问题
如果ThreadLocal要在线程池中传输，我想到的是对Runnable进行包装，在创建的时候拷贝一份ThreadLocal的值，在run方法中重新设置回去ThreadLocal中。
阿里的TransmittableThreadLocal对其的处理就是如此做的。
ThreadLocal在Hystrix中传输问题
Hystrix的处理有两种，一种线程池，一种信号量。
ThreadLocal在Hystrix中传输问题也就是线程池中传输的问题，安照上面的解决方案，我们也只需要对Runnable和Callable进行封装。
Hystrix提供HystrixPlugin让我们定制化自己的HystrixConcurrencyStrategy，HystrixConcurrencyStrategy提供对Callable进行包装的方法wrapCallable，那么我们只需要在这里对Callable进行包装即可。
