存儲結構 threadLocal存儲於Thread類上的ThreadLocalMap類型的threadLocals中。 從ThreadLocalMap的名字上可以看出其結構類似於HashMap，它也是使用key-value結構的Entry數組table來存儲ThreadLocal和值。 但區別在於E ...
存儲結構
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進行包裝即可。
