ThreadLocal：多線程環(huán)境下的神秘武器
ThreadLocal是一個線程安全的，以線程為單位的數(shù)據(jù)傳遞工具。廣泛應用于多層級數(shù)據(jù)傳遞。
1應用場景
ThreadLocal主要功能是跨層傳遞參數(shù),比如，Controller層的數(shù)據(jù)需要在業(yè)務邏輯層使用時，除了利用方法的參數(shù)傳遞之外還可以使用ThreadLocal傳遞。
有時候我們需要從上層傳遞一個參數(shù)到下層的方法，但是下層的方法新增一個參數(shù)的話，會違背開閉原則，如果依賴此方法的上層比較多，那修改此方法必然會牽扯很多其他的代碼也要改動（代碼中難免會遇到這種不合理的代碼）因此我們可以通過ThreadLocal來傳遞這個參數(shù)
另外，ThreadLocal在源碼中經(jīng)常被應用，例如，Spring MVC的RequestContextHolder的實現(xiàn)就是使用了ThreadLocal，cglib動態(tài)代理中也應用了ThreadLocal等等。
2基礎應用
public final class OperationInfoRecorder {
private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new ThreadLocal<>();
private OperationInfoRecorder() {
}
public static OperationInfoDTO get() {
return THREAD_LOCAL.get();
}
public static void set(OperationInfoDTO operationInfoDTO) {
THREAD_LOCAL.set(operationInfoDTO);
}
public static void remove() {
THREAD_LOCAL.remove();
}
}
//使用
OperationInfoRecorder.set(operationInfoDTO)
OperationInfoRecorder.get()日常的代碼書寫中需要注意兩點：
- static確保全局只有一個保存OperationInfoDTO對象的ThreadLocal實例，并且可避免內(nèi)存泄露；
- final確保ThreadLocal的實例不可更改。防止被意外改變，導致放入的值和取出來的不一致。
3架構設計
先來看看ThreadLocal設計的巧妙之處，通過一段源碼深入了解
public static void set(OperationInfoDTO operationInfoDTO) {
THREAD_LOCAL.set(operationInfoDTO);
}public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}跟到這里發(fā)現(xiàn)獲取當前線程，當前線程參與進來了，進入createMap方法
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}此處實際上就是創(chuàng)建了一個ThreadLocalMap對象，賦值給當前線程的threadLocals屬性。
我們?nèi)サ絋hread類中看看這個屬性到底是什么
public class Thread implements Runnable {
ThreadLocal.ThreadLocalMap threadLocals = null;
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
}可見每個線程對象中都有兩個屬性，這兩個屬性都是ThreadLocalMap類型。
看到這里不難想象，ThreadLocal對外聲稱的數(shù)據(jù)線程隔離不過是把數(shù)據(jù)保存到了當前線程對象里面，自然是線程隔離以及線程安全了。
4數(shù)據(jù)結構
那么ThreadLocalMap和ThreadLocal是什么關系呢？
圖片
如圖：
ThreadLocalMap內(nèi)部有一個Entry數(shù)組，這個數(shù)組中的每個元素都是一個key-value鍵值對，value是要存儲的值，key是通過WeakReference包裝的ThreadLocal對象的弱引用，弱引用會在每次垃圾回收的時候被回收。
在代碼結構上ThreadLocalMap是ThreadLocal的靜態(tài)內(nèi)部類，真正負責存儲數(shù)據(jù)的是ThreadLocalMap。
在應用上，ThreadLocal為ThreadLocalMap提供了對外訪問的api，包括set，get，remove。同時ThreadLocal對象的引用又作為ThreadLocalMap中Entry元素的key。
既然是數(shù)組，插入數(shù)據(jù)的時候是怎么解決hash沖突呢？
ThreadLocalMap采用開放尋址法插入數(shù)據(jù)。就是如果發(fā)現(xiàn)hash沖突，就依次向后面的尋找一個空桶，直到找到為止，然后插入進去。
那么為什么使用開地址法？而不是像hash表一樣使用鏈表法呢？
在開放尋址法中，所有的數(shù)據(jù)都存儲在一個數(shù)組中，比起鏈表法來說，沖突的代價更高。所以，使用開放尋址法解決沖突的散列表，裝載因子的上限不能太大。這也導致這種方法比鏈表法更浪費內(nèi)存空間。但是反過看，鏈表法指針需要額外的空間，故當結點規(guī)模較小時，開放尋址法較為節(jié)省空間，而若將節(jié)省的指針空間用來擴大散列表的規(guī)模，可使裝填因子變小，這又減少了開放尋址法中的沖突，從而提高平均查找速度。并且使用中很少有大量ThreadLocal對象的場景。
5源碼解析
set方法解析
1.第一次set數(shù)據(jù)
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
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);
}第一次set數(shù)據(jù)比較簡單，線程中尚未初始化ThreadLocalMap，需要先初始化，初始化步驟如下：
- 聲明數(shù)組
- 計算下標
- 給對應數(shù)組下標賦值
- 設置當前數(shù)組長度size
- 數(shù)組長度計算擴容因子Threshold
1.非第一次set數(shù)據(jù)
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();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}上面的代碼步驟如下：
- 計算下標
- 如果當前下標無數(shù)據(jù)，直接進入4。
- 如果當前下標有數(shù)據(jù)，則從當前下標開始向后遍歷，每遍歷一次，i++
3.1 如果當前下標桶中的Entry對象的k和需要保存的key相同，直接更新，結束
3.2 如果當前下標桶中的Entry對象的k和需要保存的key不相同，且k不為空，不處理
3.3 如果當前下標桶中的Entry對象的k為空，說明當前Entry對象已經(jīng)失效無用，需要進行進一步處理
3.4 進入replaceStaleEntry方法，結束 - 如果到現(xiàn)在沒有結束方法，則創(chuàng)建Entry賦值給下標i對應的桶，注意這里的i不一定是最開始值了。
private void replaceStaleEntry(ThreadLocal<?> key, Object value,
int staleSlot) {
Entry[] tab = table;
int len = tab.length;
Entry e;
int slotToExpunge = staleSlot;
for (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len)){
if (e.get() == null)
slotToExpunge = i;
}
for (int i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
if (slotToExpunge == staleSlot)
slotToExpunge = i;
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
if (k == null && slotToExpunge == staleSlot)
slotToExpunge = i;
}
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}replaceStaleEntry方法是對set過程中遇到的失效Entry做進一步處理，replaceStaleEntry代碼中執(zhí)行步驟如下：
1. 從當前下標為staleSlot的地方向左遍歷，直到找到第一個空桶停止遍歷，此時slotToExpunge=staleSlot，或者直到找到第一個非空桶且Entry對象的key為空為止，此時slotToExpunge為當前桶下標。此處可能說的有點繞，但是相信自己看代碼就能明白。
2. 從當前下標為staleSlot的地方向右遍歷，此遍歷的目的是為了查看右側是否存在key相同的Entry，如果有，就更新value，并且和staleSlot下標對應的桶中的失效Entry交換位置，如果沒有就直接更新staleSlot下標的桶。
這里為什么不直接更新staleSlot下標對應的桶呢？
因為Entry數(shù)組插入的時候如果遇到hash沖突(即兩個key計算出的下標相同)，直接是依次插到后面一個空桶，如果再后來的數(shù)據(jù)插入的時候發(fā)現(xiàn)對應下標的桶已經(jīng)被占用，這種情況也是向后一個空桶插入。因此可以知道，不直接更新而是向后遍歷查看key是否相等，就類似于hash表插入的時候發(fā)生hash沖突后對鏈表的遍歷查找。只不過多了一個為止交換。
3. 每一次插入完成，就要執(zhí)行expungeStaleEntry方法和cleanSomeSlots方法，這個兩個方法都是失效清理方法。
expungeStaleEntry方法為探測式清理，從給定開始的下標開始向右遍歷，直到第一個空桶為止
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
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;
}還記得這個變量嗎slotToExpunge，這個變量的值是向左遍歷得到的第一個Entry失效的桶的下標。
此方法做的事情就是從這個下標開始向右把失效的Entry全部清除，而把沒有失效的Entry重新計算下標，重新按照開放地址法放到數(shù)組中。直到第一個空桶停止遍歷。并且把當前遍歷到的桶的下標返回。
我們先來總結下這個過程的幾個關鍵點
- 向左遍歷到第一個空桶的位置。
- 向右遍歷的過程中清除失效Entry，重hash有效Entry，直到遍歷到第一個空桶為止。
那么為什么這么做呢？
首先，之所以只操作兩個空桶之間的元素，是因為兩個空桶之間的元素都和當前key計算的下標有關系（有可能是hash沖突造成的臨近元素），操作這一部分數(shù)據(jù)可以保證與當前key相關的元素都能得到失效處理。
然后就是小范圍的失效操作，避免大量數(shù)據(jù)參與，可以提高性能。
最后是可以使得rehash后的數(shù)據(jù)距離正確的位置更近一些，能提高整個散列表的查詢性能。
同時這個方法會在set，get，remove，resize方法中反復使用，因此不能大規(guī)模掃描。
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;
}cleanSomeSlots方法為啟發(fā)式清理，從給定開始的下標開始向右遍歷log2n個位置，對遍歷過程中失效元素調(diào)用expungeStaleEntry方法，目的也是在不影響性能的基礎上盡可能的多的把失效的元素清除。
get方法解析
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
private Entry getEntry(ThreadLocal<?> key) {
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
}
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;
while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}get方法要比set方法簡單，邏輯步驟如下
- 計算下標，通過下標獲取元素
- 對比下標對應桶中元素的key和要查詢k是否相等，如果相等直接返回
- 如果key不相等，就會走這個getEntryAfterMiss方法
getEntryAfterMiss方法就是從當前坐標開始向后檢查key是否相等，相等的直接返回，如果失效，就調(diào)用expungeStaleEntry做失效處理，如果沒有找到就返回null。
remove方法解析
private void remove(ThreadLocal<?> key) {
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)]) {
if (e.get() == key) {
e.clear();
expungeStaleEntry(i);
return;
}
}
}remove方法就更加簡單了，遍歷找到key相等的元素，進行刪除，順便在當前坐標位置開始調(diào)用expungeStaleEntry進行失效處理
擴容解析
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
int newLen = oldLen * 2;
Entry[] newTab = new Entry[newLen];
int count = 0;
for (int j = 0; j < oldLen; ++j) {
Entry e = oldTab[j];
if (e != null) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null; // Help the GC
} else {
int h = k.threadLocalHashCode & (newLen - 1);
while (newTab[h] != null)
h = nextIndex(h, newLen);
newTab[h] = e;
count++;
}
}
}
setThreshold(newLen);
size = count;
table = newTab;
}擴容機制也比較簡單，在擴容前會先調(diào)用expungeStaleEntry進行一次失效處理，這此失效處理是在坐標0開始，失效處理結束后如果size >= threshold - threshold / 4，那就進行擴容
擴容步驟
- 聲明新的數(shù)組，是原來數(shù)據(jù)的2倍
- 遍歷原來的數(shù)組，對元素進行重hash計算下標，然后放入新的數(shù)組中。
- 遍歷過程中如果遇到失效的元素，value置為空。
- 重置size,重置table，重新計算擴容因子threshold,(len * 2 / 3)
6ThreadLocal的問題
內(nèi)存泄露
在ThreadLocalMap中使用WeakReference包裝后的ThreadLocal對象作為key，也就是說這里對ThreadLocal對象為弱引用。當ThreadLocal對象在ThreadLocalMap引用之外，再無其他引用的時候能夠被垃圾回收
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}垃圾回收后，Entry對象的key變?yōu)閚ull，value還被引用著，既然key為null，那么value就不可能再被應用，但是因為value被Entry引用著，Entry被ThreadLocalMap引用著，ThreadLocalMap被Thread引用著，因此線程不結束，那么該回收的內(nèi)存就會一直回收不了。
很容易出問題的情況就是我們在使用線程池的時候，線程池中的線程都是重復利用的，這時候使用threadLocal存放一些數(shù)據(jù)的話，如果在線程結束的時候沒有顯示的做清除處理，就有可能會出現(xiàn)內(nèi)存泄露問題，甚至導致業(yè)務邏輯出現(xiàn)問題。所以在使用線程池的時候需要特別注意在代碼運行完后顯式的去清空設置的數(shù)據(jù)，如果用自定義的線程池同樣也會遇到這樣的問題。此時需要在finally代碼塊顯式清除threadLocal中的數(shù)據(jù)。
當然對于內(nèi)存泄露問題，ThreadLocalMap也是做了相關處理的，通過上面的源碼知道ThreadLocalMap在get和set以及remove的時候,都會相應的做一次探測式清理操作，但是我們也說了這種清除是小范圍的，是不能100%保證能夠清理干凈的。
我們可以通過以下兩種方式來避免這個問題：
把ThreadLocal對象聲明為static，這樣ThreadLocal成為了類變量，生命周期不是和對象綁定，而是和類綁定，延長了聲明周期，避免了被回收；
在使用完ThreadLocal變量后，手動remove掉，防止ThreadLocalMap中Entry一直保持對value的強引用。導致value不能被回收。
threadlocal的繼承性
threadlocal不支持繼承性：也就是說，同一個ThreadLocal變量在父線程中被設置值后，在子線程中是獲取不到的。
但是父線程設置上下文就無法被子線程獲取嗎？當然不是，thread類除了提供了threadLocals，還提供了inheritableThreadLocals，InheritableThreadLocal繼承了ThreadLocal，這個類中的父線程的值就可以在子線程中獲取到。此類重寫了ThreadLocal的三個方法。
public class InheritableThreadLocal<T> extends ThreadLocal<T> {
public InheritableThreadLocal() {
}
protected T childValue(T var1) {
return var1;
}
ThreadLocalMap getMap(Thread var1) {
return var1.inheritableThreadLocals;
}
void createMap(Thread var1, T var2) {
var1.inheritableThreadLocals = new ThreadLocalMap(this, var2);
}
}此類是如何實現(xiàn)子線程獲取父線程保存的值的呢？下面代碼是thread類的源碼，在創(chuàng)建一個線程時，thread初始化的innt方法中會去判斷父線程的inheritThreadLocals中是否有值，如果有，直接賦值給子線程
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);InheritableThreadLocals的使用方式
private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new InheritableThreadL
