1、基礎概念
Stack & Heap
Stack和Heap是我們常說的棧和堆，這裏不做贅述，只需要備註一點知識即可，Stack是線程私有獨享且線程安全的，Heap是所有線程共享非線程安全的。TheadLocal的設計初衷就是希望讓線程擁有了自己內部獨享的變量，每個線程之間隔離互不干擾以起到線程安全的目的。
ThreadLocal
- ThreadLocal是我們所說的線程本地變量。如上圖所示，它的內部封裝了一個非常重要的數據結構ThreadLocalMap來提供線程變量數據的真實獲取、存儲及移除等操作。我們可以把ThreadLocal理解稱爲一個封裝類或是一箇中介對象，所有的核心方法如get、set、remove等都通過ThreadLocal來提供和交互，而真正的幕後大佬是ThreadLocalMap這個封裝了最終方法邏輯和內部數據結構的內部類。
private static AtomicInteger nextHashCode = new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
- ThreadLocal內部還持有一個實例變量threadLocalHashCode，它是一個哈希值用來做ThreadLocalMap中Entry哈希表路由計算的，threadLocalHashCode的生成方式是根據HASH_INCREMENT這個哈希魔數進行自加操作，關於哈希算法這部分後面會提到。
ThreadLocalMap
static class ThreadLocalMap {
// hash map中的entry繼承自弱引用WeakReference，指向threadLocal對象
// 對於key爲null的entry，說明不再需要訪問，會從table表中清理掉
// 這種entry被成爲“stale entries”
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
private static final int INITIAL_CAPACITY = 16;
private Entry[] table;
private int size = 0;
private int threshold; // Default to 0
private void setThreshold(int len) {
threshold = len * 2 / 3;
}
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);
}
}
- ThreadLocalMap是一個自定義的hash map，專門用來保存線程的thread local變量
- 它的操作僅限於ThreadLocal類中，不對外暴露
- 這個類被用在Thread類的私有變量threadLocals和inheritableThreadLocals上
- 爲了能夠保存大量且存活時間較長的threadLocal實例，hash table entries採用了WeakReferences作爲key的類型
- 一旦hash table運行空間不足時，key爲null的entry就會被清理掉
Entry
這裏的Entry繼承了WeakReference類，它的內部構成是一個鍵值對結構，Key是弱引用的referant，是從WeakReference對象繼承而來的，Value是實際存儲的線程變量對象數據，即<K,V>=<Referant,Object>，而這裏Entry進行了泛型限制，最終定義爲Entry<ThrealLocal,Object>的數據格式
2、源碼核心方法解析
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();
}
- 獲取當前線程內部的ThreadLocalMap
- map存在則獲取當前ThreadLocal對應的value值
- map不存在或者找不到value值，則調用setInitialValue，進行初始化
setInitialValue()源碼
private T setInitialValue() {
T value = initialValue();
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
return value;
}
- 調用initialValue方法，獲取初始化值【調用者通過覆蓋該方法，設置自己的初始化值】
- 獲取當前線程內部的ThreadLocalMap
- map存在則把當前ThreadLocal和value添加到map中
- map不存在則創建一個ThreadLocalMap，保存到當前線程內部
get()方法時序圖
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);
}
- 獲取當前線程內部的ThreadLocalMap
- map存在則把當前ThreadLocal和value添加到map中
- map不存在則創建一個ThreadLocalMap，保存到當前線程內部
remove()源碼
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
m.remove(this);
}
remove()方法時序圖
3、核心算法
哈希值生成算法
哈希值生成算法：HASH_INCREMENT是參與哈希計算的哈希魔數，這裏是16進制的0x61c88647，轉換爲10進制就是-1640531527,
每次自增HASH_INCREMENT進行生成，這裏使用了AtomicInteger保證了線程安全
索引生成算法
索引生成算法：key.threadLocalHashCode & (len-1)
- key.threadLocalHashCode即通過HASH_INCREMENT自增1得到的哈希值
- len即當前哈希槽的容量，初始化默認是16，即時哈希槽擴容也是保持16的2倍，可以理解爲2的N次方
- 綜上，索引生成是（HASH_INCREMENT自增HASH_INCREMENT）&（2的N次方-1）
黃金分割數
ThreadLocalMap採用黃金分割數的方式，大大降低了哈希衝突的情況。
- 黃金分割數： int的黃金分割數是按照int的最大值2147483647乘以黃金分割比例Math.sqrt(5) - 1) / 2 計算得來的，最終int的黃金分割數爲-1640531527。
- 哈希魔數： 哈希數是通過哈希魔數HASH_INCREMENT加自身進行變更，經過研究發現這樣會具有更好的散列性。
- 高低位：（2的N次方-1）生成的數字均有一個特點，二進制高位爲0，低位爲1
- 高效按位與：（HASH_INCREMENT自增HASH_INCREMENT）&（2的N次方-1）是索引生成的算法，因爲是按位與運算，且（2的N次方-1）高位爲0，低位爲1，因此變成了HashCode &（2的N次方-1）= HashCode %（2的N次方-1）的運算，但是按位與運算效率要高於取模運算
（2的N次方-1）的二進制
2的1次方 num:1 binary:00000000000000000000000000000001
2的2次方 num:3 binary:00000000000000000000000000000011
2的3次方 num:7 binary:00000000000000000000000000000111
2的4次方 num:15 binary:00000000000000000000000000001111
2的5次方 num:31 binary:00000000000000000000000000011111
2的6次方 num:63 binary:00000000000000000000000000111111
2的7次方 num:127 binary:00000000000000000000000001111111
2的8次方 num:255 binary:00000000000000000000000011111111
2的9次方 num:511 binary:00000000000000000000000111111111
2的10次方 num:1023 binary:00000000000000000000001111111111
2的11次方 num:2047 binary:00000000000000000000011111111111
2的12次方 num:4095 binary:00000000000000000000111111111111
2的13次方 num:8191 binary:00000000000000000001111111111111
2的14次方 num:16383 binary:00000000000000000011111111111111
2的15次方 num:32767 binary:00000000000000000111111111111111
2的16次方 num:65535 binary:00000000000000001111111111111111
2的17次方 num:131071 binary:00000000000000011111111111111111
2的18次方 num:262143 binary:00000000000000111111111111111111
2的19次方 num:524287 binary:00000000000001111111111111111111
2的20次方 num:1048575 binary:00000000000011111111111111111111
2的21次方 num:2097151 binary:00000000000111111111111111111111
2的22次方 num:4194303 binary:00000000001111111111111111111111
2的23次方 num:8388607 binary:00000000011111111111111111111111
2的24次方 num:16777215 binary:00000000111111111111111111111111
2的25次方 num:33554431 binary:00000001111111111111111111111111
2的26次方 num:67108863 binary:00000011111111111111111111111111
2的27次方 num:134217727 binary:00000111111111111111111111111111
2的28次方 num:268435455 binary:00001111111111111111111111111111
2的29次方 num:536870911 binary:00011111111111111111111111111111
2的30次方 num:1073741823 binary:00111111111111111111111111111111
不難發現，2的冪次方-1的數字的二進制有一個特點那就是，高位都是0，,低位都是1。
（HASH_INCREMENT自增HASH_INCREMENT）的二進制
id:1 hashCode:1640531527 binary:01100001110010001000011001000111
id:2 hashCode:-1013904242 binary:11000011100100010000110010001110
id:3 hashCode:626627285 binary:00100101010110011001001011010101
id:4 hashCode:-2027808484 binary:10000111001000100001100100011100
id:5 hashCode:-387276957 binary:11101000111010101001111101100011
id:6 hashCode:1253254570 binary:01001010101100110010010110101010
id:7 hashCode:-1401181199 binary:10101100011110111010101111110001
id:8 hashCode:239350328 binary:00001110010001000011001000111000
id:9 hashCode:1879881855 binary:01110000000011001011100001111111
id:10 hashCode:-774553914 binary:11010001110101010011111011000110
id:11 hashCode:865977613 binary:00110011100111011100010100001101
id:12 hashCode:-1788458156 binary:10010101011001100100101101010100
id:13 hashCode:-147926629 binary:11110111001011101101000110011011
id:14 hashCode:1492604898 binary:01011000111101110101011111100010
id:15 hashCode:-1161830871 binary:10111010101111111101111000101001
id:16 hashCode:478700656 binary:00011100100010000110010001110000
id:17 hashCode:2119232183 binary:01111110010100001110101010110111
id:18 hashCode:-535203586 binary:11100000000110010111000011111110
id:19 hashCode:1105327941 binary:01000001111000011111011101000101
id:20 hashCode:-1549107828 binary:10100011101010100111110110001100
id:21 hashCode:91423699 binary:00000101011100110000001111010011
id:22 hashCode:1731955226 binary:01100111001110111000101000011010
id:23 hashCode:-922480543 binary:11001001000001000001000001100001
id:24 hashCode:718050984 binary:00101010110011001001011010101000
id:25 hashCode:-1936384785 binary:10001100100101010001110011101111
id:26 hashCode:-295853258 binary:11101110010111011010001100110110
id:27 hashCode:1344678269 binary:01010000001001100010100101111101
id:28 hashCode:-1309757500 binary:10110001111011101010111111000100
id:29 hashCode:330774027 binary:00010011101101110011011000001011
id:30 hashCode:1971305554 binary:01110101011111111011110001010010
id:31 hashCode:-683130215 binary:11010111010010000100001010011001
以上通過nextHashCode.getAndAdd(HASH_INCREMENT)生成32次hashCode。
由於（2的N次方-1）的二進制高位均爲1，且是&運算，因此hashCode越具有散列性，最終索引值也會具有很好的散列性，哈希碰撞的可能性就會減少。
在（2的N次方-1）的二進制也就是length固定的情況下，低位都是1，高位都是0，因此，hashCode高位或低位相同太多會導致嚴重碰撞，一定要如上圖這樣到高低位都能具有很好的差異性參與計算纔可以減少碰撞
id:1 hashCode:1640531527 index:7
id:2 hashCode:-1013904242 index:14
id:3 hashCode:626627285 index:21
id:4 hashCode:-2027808484 index:28
id:5 hashCode:-387276957 index:3
id:6 hashCode:1253254570 index:10
id:7 hashCode:-1401181199 index:17
id:8 hashCode:239350328 index:24
id:9 hashCode:1879881855 index:31
id:10 hashCode:-774553914 index:6
id:11 hashCode:865977613 index:13
id:12 hashCode:-1788458156 index:20
id:13 hashCode:-147926629 index:27
id:14 hashCode:1492604898 index:2
id:15 hashCode:-1161830871 index:9
id:16 hashCode:478700656 index:16
id:17 hashCode:2119232183 index:23
id:18 hashCode:-535203586 index:30
id:19 hashCode:1105327941 index:5
id:20 hashCode:-1549107828 index:12
id:21 hashCode:91423699 index:19
id:22 hashCode:1731955226 index:26
id:23 hashCode:-922480543 index:1
id:24 hashCode:718050984 index:8
id:25 hashCode:-1936384785 index:15
id:26 hashCode:-295853258 index:22
id:27 hashCode:1344678269 index:29
id:28 hashCode:-1309757500 index:4
id:29 hashCode:330774027 index:11
id:30 hashCode:1971305554 index:18
id:31 hashCode:-683130215 index:25
id:32 hashCode:957401312 index:0
以上是length爲32時，生成的32次索引值的情況，發現索引值分佈非常均勻，沒有出現碰撞。
哈希衝突解決
當出現哈希衝突時，它的做法看是否是同一個對象或者是是否可以替換，否則往後移動一位，繼續判斷，這裏採用的是再次尋址的方法。
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
內存清理
ThreadLocal之所以採用Entry的key使用弱引用就是爲了儘快回收避免大量佔用內存空間，除此之外還創造性的增加了探測式清理、啓發式清理兩種方式在覈心方法get、set等調用時進行內存對象的回收和清理工作
探測式清理
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// 因爲entry對應的ThreadLocal已經被回收，value設爲null，顯式斷開強引用
tab[staleSlot].value = null;
// 顯式設置該entry爲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();
// 清理對應ThreadLocal已經被回收的entry
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
/*
* 對於還沒有被回收的情況，需要做一次rehash。
*
* 如果對應的ThreadLocal的ID對len取模出來的索引h不爲當前位置i，
* 則從h向後線性探測到第一個空的slot，把當前的entry給挪過去。
*/
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.
*
* 這段話提及了Knuth高德納的著作TAOCP（《計算機程序設計藝術》）的6.4章節（散列）
* 中的R算法。R算法描述瞭如何從使用線性探測的散列表中刪除一個元素。
* R算法維護了一個上次刪除元素的index，當在非空連續段中掃到某個entry的哈希值取模後的索引
* 還沒有遍歷到時，會將該entry挪到index那個位置，並更新當前位置爲新的index，
* 繼續向後掃描直到遇到空的entry。
*
* ThreadLocalMap因爲使用了弱引用，所以其實每個slot的狀態有三種也即
* 有效（value未回收），無效（value已回收），空（entry==null）。
* 正是因爲ThreadLocalMap的entry有三種狀態，所以不能完全套高德納原書的R算法。
*
* 因爲expungeStaleEntry函數在掃描過程中還會對無效slot清理將之轉爲空slot，
* 如果直接套用R算法，可能會出現具有相同哈希值的entry之間斷開（中間有空entry）。
*/
while (tab[h] != null) {
h = nextIndex(h, len);
}
tab[h] = e;
}
}
}
// 返回staleSlot之後第一個空的slot索引
return i;
}
- 根據場景改進了高德納論述的從使用線性探測的散列表中刪除一個元素的R算法
- 如果index對應的slot就是要讀的threadLocal，則直接返回結果
- 調用getEntryAfterMiss線性探測，過程中每碰到無效slot，調用expungeStaleEntry進行段清理；如果找到了key，則返回結果entry
- 沒有找到key，返回null
啓發式清理
private boolean cleanSomeSlots(int i, int n) {
boolean removed = false;
Entry[] tab = table;
int len = tab.length;
do {
// i在任何情況下自己都不會是一個無效slot，所以從下一個開始判斷
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;
}
- 啓發式地清理slot,i對應entry是非無效（指向的ThreadLocal沒被回收，或者entry本身爲空），n是用於控制控制掃描次數的
- 正常情況下如果log n次掃描沒有發現無效slot，函數就結束了
- 但是如果發現了無效的slot，將n置爲table的長度len，做一次連續段的清理，再從下一個空的slot開始繼續掃描
- 這個函數有兩處地方會被調用，一處是插入的時候可能會被調用，另外個是在替換無效slot的時候可能會被調用，區別是前者傳入的n爲元素個數，後者爲table的容量
4、缺點
內存泄露問題
如上圖，整理對象引用關係，用**++>表示強引用，用–>**表示弱引用
- Thread ++> ThrealLocal.ThreadLocalMap ++> Entry ++> key (referant) --> ThreadLocal
- Thread ++> ThrealLocal.ThreadLocalMap ++> Entry ++> value ++> Object
由於key (referant) --> ThreadLocal是弱引用，gc時會回收key，此時key爲null，但是Thread作爲這條引用鏈的Root根不會立刻線程執行完畢而消失，會一直駐留在Stack中，這種情況一般可以有兩種，一個事在一個for循環中執行，一種是線程池中執行，因此會導致強引用的value不會進行釋放對象導致內存溢出
父子線程無法傳遞線程副本數據
在主線程中使用ThreadLocal無法直接傳遞給子線程，如果要操作還需要通過線程封閉進行變量置換。
5、問題彙總
- ThreadLocal的key是弱引用，那麼在 threadLocal.get()的時候,發生GC之後，key是否爲null？
由於Entry<WeakReference,Object>的key是弱引用，GC後就會被回收 - ThreadLocal中ThreadLocalMap的數據結構？
哈希表 - ThreadLocalMap的Hash算法？
key.threadLocalHashCode & (length -1) , length爲2的冪次方 - ThreadLocalMap中Hash衝突如何解決？
開放地址，二次尋址，由於使用黃金分割數進行哈希計算，散列非常好，出現碰撞的可能性很低，所以沒有像HashMap那樣進行鏈地址解決衝突 - ThreadLocalMap擴容機制？
length2/3 觸發rehash邏輯，進行探測式清理，最終判斷size >= threshold 3/4來決定是否要真正擴容調用resize方法 - ThreadLocalMap中過期key的清理機制？探測式清理和啓發式清理流程？
探測式清理(expungeStaleEntry())、啓發式清理(cleanSomeSlots())
探測式清理是以當前Entry 往後清理，遇到值爲null則結束清理，屬於線性探測清理，結合了 - ThreadLocalMap.set()方法實現原理？
略 - ThreadLocalMap.get()方法實現原理？
略 - 項目中ThreadLocal使用情況？遇到的坑？
父子線程不能傳遞線程變量，主線程中使用線程池相當於父線程中使用子線程無法傳值
6、實戰應用
複雜場景
Spring容器、RPC全鏈路traceId傳遞等
應用舉例
在單體應用中一般不會聲明多個ThreadLocal，即不會讓Thread中持有的ThreadLocalMap的key有多個，由於ThreadLocal是支持泛型的，我們可以傳入一個線程安全的容器，讓Thread內持有的ThreadLocalMap中只有一個key，即只有一個ThreadLocal的key引用，而存儲的Object可以是一個Map或者List，我們根據業務場景操作容器即可，大部分情況都可以滿足，設計合理的話是可以共用的，減少持有key也不會佔用大量的棧空間，且把ThreadLocal聲明爲private final static，下面提供一個demo：
/**
* @author: guanjian
* @date: 2020/07/08 9:31
* @description: 環境變量
*/
@Component("contextHolder")
public class ContextHolder<T, R> {
private final static Logger LOGGER = LoggerFactory.getLogger(ContextHolder.class);
/**
* 入參對象
*/
public final static String REQUEST_PARAM = "request_param";
/**
* 出參對象
*/
public final static String RESPONSE_PARAM = "response_param";
/**
* 傳值對象
*/
public final static String TRANSMIT_PARAM = "transmit_param";
/**
* 線程變量
*/
private final static ThreadLocal<Map<Object, Object>> localVariable = ThreadLocal.withInitial(() -> Maps.newHashMap());
public void bindLocal(Object key, Object value) {
Objects.requireNonNull(key, "key can not be null");
Map holder = localVariable.get();
holder.put(key, value);
localVariable.set(holder);
LOGGER.debug("[ContextHolder] key={},value={} binded.", key, JSON.toJSONString(value));
}
public Object getLocal(Object key) {
if (CollectionUtils.isEmpty(localVariable.get())) return null;
Object value = localVariable.get().get(key);
LOGGER.debug("[ContextHolder] key={},value={} getted.", key, JSON.toJSONString(value));
return value;
}
public void bindRequest(T value) {
bindLocal(REQUEST_PARAM, value);
}
public T getRequest() {
return (T) localVariable.get().get(REQUEST_PARAM);
}
public void bindResponse(R value) {
bindLocal(RESPONSE_PARAM, value);
}
public R getResponse() {
return (R) localVariable.get().get(RESPONSE_PARAM);
}
public void bindTransmit(Object value) {
bindLocal(TRANSMIT_PARAM, value);
}
public Object getTransmit() {
return getLocal(TRANSMIT_PARAM);
}
public void clear() {
localVariable.remove();
}
}
7、參考
https://www.cnblogs.com/wang-meng/p/12856648.html
https://blog.csdn.net/zjcsuct/article/details/104310194
http://www.iocoder.cn/JDK/ThreadLocal/
https://blog.csdn.net/qq_22167989/article/details/89448670