存盤結構
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 = https://www.cnblogs.com/wuweishuo/p/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 = https://www.cnblogs.com/wuweishuo/p/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進行包裝即可，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/137665.html
標籤：Java
上一篇：一步步教你用Prometheus搭建實時監控系統系列(一)——上帝之火，普羅米修斯的崛起
下一篇：Java NIO的理解和應用