深入理解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進行包裝即可。