ThreadLocal是一個線程安全的,以線程為單位的數據傳遞工具。廣泛應用于多層級數據傳遞。
ThreadLocal主要功能是跨層傳遞參數,比如,Controller層的數據需要在業務邏輯層使用時,除了利用方法的參數傳遞之外還可以使用ThreadLocal傳遞。
有時候我們需要從上層傳遞一個參數到下層的方法,但是下層的方法新增一個參數的話,會違背開閉原則,如果依賴此方法的上層比較多,那修改此方法必然會牽扯很多其他的代碼也要改動(代碼中難免會遇到這種不合理的代碼)因此我們可以通過ThreadLocal來傳遞這個參數
另外,ThreadLocal在源碼中經常被應用,例如,Spring MVC的RequestContextHolder的實現就是使用了ThreadLocal,cglib動態代理中也應用了ThreadLocal等等。
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()
日常的代碼書寫中需要注意兩點:
先來看看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); }
跟到這里發現獲取當前線程,當前線程參與進來了,進入createMap方法
void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue);}
此處實際上就是創建了一個ThreadLocalMap對象,賦值給當前線程的threadLocals屬性。
我們去到Thread類中看看這個屬性到底是什么
public class Thread implements Runnable {ThreadLocal.ThreadLocalMap threadLocals = null;ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;}
可見每個線程對象中都有兩個屬性,這兩個屬性都是ThreadLocalMap類型。
看到這里不難想象,ThreadLocal對外聲稱的數據線程隔離不過是把數據保存到了當前線程對象里面,自然是線程隔離以及線程安全了。
那么ThreadLocalMap和ThreadLocal是什么關系呢?
圖片
如圖:
ThreadLocalMap內部有一個Entry數組,這個數組中的每個元素都是一個key-value鍵值對,value是要存儲的值,key是通過WeakReference包裝的ThreadLocal對象的弱引用,弱引用會在每次垃圾回收的時候被回收。
在代碼結構上ThreadLocalMap是ThreadLocal的靜態內部類,真正負責存儲數據的是ThreadLocalMap。
在應用上,ThreadLocal為ThreadLocalMap提供了對外訪問的api,包括set,get,remove。同時ThreadLocal對象的引用又作為ThreadLocalMap中Entry元素的key。
既然是數組,插入數據的時候是怎么解決hash沖突呢?
ThreadLocalMap采用開放尋址法插入數據。就是如果發現hash沖突,就依次向后面的尋找一個空桶,直到找到為止,然后插入進去。
那么為什么使用開地址法?而不是像hash表一樣使用鏈表法呢?
在開放尋址法中,所有的數據都存儲在一個數組中,比起鏈表法來說,沖突的代價更高。所以,使用開放尋址法解決沖突的散列表,裝載因子的上限不能太大。這也導致這種方法比鏈表法更浪費內存空間。但是反過看,鏈表法指針需要額外的空間,故當結點規模較小時,開放尋址法較為節省空間,而若將節省的指針空間用來擴大散列表的規模,可使裝填因子變小,這又減少了開放尋址法中的沖突,從而提高平均查找速度。并且使用中很少有大量ThreadLocal對象的場景。
1.第一次set數據
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數據比較簡單,線程中尚未初始化ThreadLocalMap,需要先初始化,初始化步驟如下:
1.非第一次set數據
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(); }
上面的代碼步驟如下:
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代碼中執行步驟如下:
1. 從當前下標為staleSlot的地方向左遍歷,直到找到第一個空桶停止遍歷,此時slotToExpunge=staleSlot,或者直到找到第一個非空桶且Entry對象的key為空為止,此時slotToExpunge為當前桶下標。此處可能說的有點繞,但是相信自己看代碼就能明白。
2. 從當前下標為staleSlot的地方向右遍歷,此遍歷的目的是為了查看右側是否存在key相同的Entry,如果有,就更新value,并且和staleSlot下標對應的桶中的失效Entry交換位置,如果沒有就直接更新staleSlot下標的桶。
這里為什么不直接更新staleSlot下標對應的桶呢?
因為Entry數組插入的時候如果遇到hash沖突(即兩個key計算出的下標相同),直接是依次插到后面一個空桶,如果再后來的數據插入的時候發現對應下標的桶已經被占用,這種情況也是向后一個空桶插入。因此可以知道,不直接更新而是向后遍歷查看key是否相等,就類似于hash表插入的時候發生hash沖突后對鏈表的遍歷查找。只不過多了一個為止交換。
3. 每一次插入完成,就要執行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重新計算下標,重新按照開放地址法放到數組中。直到第一個空桶停止遍歷。并且把當前遍歷到的桶的下標返回。
我們先來總結下這個過程的幾個關鍵點
那么為什么這么做呢?
首先,之所以只操作兩個空桶之間的元素,是因為兩個空桶之間的元素都和當前key計算的下標有關系(有可能是hash沖突造成的臨近元素),操作這一部分數據可以保證與當前key相關的元素都能得到失效處理。
然后就是小范圍的失效操作,避免大量數據參與,可以提高性能。
最后是可以使得rehash后的數據距離正確的位置更近一些,能提高整個散列表的查詢性能。
同時這個方法會在set,get,remove,resize方法中反復使用,因此不能大規模掃描。
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方法為啟發式清理,從給定開始的下標開始向右遍歷log2n個位置,對遍歷過程中失效元素調用expungeStaleEntry方法,目的也是在不影響性能的基礎上盡可能的多的把失效的元素清除。
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方法簡單,邏輯步驟如下
getEntryAfterMiss方法就是從當前坐標開始向后檢查key是否相等,相等的直接返回,如果失效,就調用expungeStaleEntry做失效處理,如果沒有找到就返回null。
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相等的元素,進行刪除,順便在當前坐標位置開始調用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; }
擴容機制也比較簡單,在擴容前會先調用expungeStaleEntry進行一次失效處理,這此失效處理是在坐標0開始,失效處理結束后如果size >= threshold - threshold / 4,那就進行擴容
擴容步驟
在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變為null,value還被引用著,既然key為null,那么value就不可能再被應用,但是因為value被Entry引用著,Entry被ThreadLocalMap引用著,ThreadLocalMap被Thread引用著,因此線程不結束,那么該回收的內存就會一直回收不了。
很容易出問題的情況就是我們在使用線程池的時候,線程池中的線程都是重復利用的,這時候使用threadLocal存放一些數據的話,如果在線程結束的時候沒有顯示的做清除處理,就有可能會出現內存泄露問題,甚至導致業務邏輯出現問題。所以在使用線程池的時候需要特別注意在代碼運行完后顯式的去清空設置的數據,如果用自定義的線程池同樣也會遇到這樣的問題。此時需要在finally代碼塊顯式清除threadLocal中的數據。
當然對于內存泄露問題,ThreadLocalMap也是做了相關處理的,通過上面的源碼知道ThreadLocalMap在get和set以及remove的時候,都會相應的做一次探測式清理操作,但是我們也說了這種清除是小范圍的,是不能100%保證能夠清理干凈的。
我們可以通過以下兩種方式來避免這個問題:
把ThreadLocal對象聲明為static,這樣ThreadLocal成為了類變量,生命周期不是和對象綁定,而是和類綁定,延長了聲明周期,避免了被回收;
在使用完ThreadLocal變量后,手動remove掉,防止ThreadLocalMap中Entry一直保持對value的強引用。導致value不能被回收。
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); }}
此類是如何實現子線程獲取父線程保存的值的呢?下面代碼是thread類的源碼,在創建一個線程時,thread初始化的innt方法中會去判斷父線程的inheritThreadLocals中是否有值,如果有,直接賦值給子線程
if (inheritThreadLocals && parent.inheritableThreadLocals != null) this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
InheritableThreadLocals的使用方式
private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new InheritableThreadL
本文鏈接:http://www.tebozhan.com/showinfo-26-14116-0.htmlThreadLocal:多線程環境下的神秘武器
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
下一篇: 壓測工具界的 “悍馬” :wrk 使用