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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/222709.html
標籤：AI
上一篇：Springboot進行hibernate-vidator資料驗證
下一篇：Tomcat原始碼學習記錄