ThreadLocal,ThreadLocalMap,Thread 的相互關係以及設計原理分析
阿新 • • 發佈：2019-01-31
一句話，ThreadLocal並不是把執行緒作為key，值作為value的類似一種HashMap的東西。而是每個Thread裡面都有一個ThreadLocalMap的集合，ThreadLocal只是操作每個執行緒的ThreadLocalMap而已。
轉：http://www.iteye.com/topic/1007515
1.ThreadLocal.
真正關鍵的類是它的內部類ThreadLocalMap,ThreadLocal 基本上相當於一個代理，或者算是Facade模式的應用，還沒想清楚這種設計的妙處。(經過分析，這種安排與弱引用的特性有關)
2.同時，Thread類中包含一個ThreadLocalMap型別的成員變數。
3.ThreadLocalMap的實現原理跟HashMap差不多，內部有一個Entry陣列，一個Entry通常至少包括key,value, 查詢時通過一定的運算規則運算Key的HASH值，來得到Entry在陣列中的位置，進而得到相應的value。但是比較特殊的是，
<1>這個Entry繼承了WeakReference，
注意super(K) 這句，它實際上真正弱引用的是ThreadLocal物件。static class Entry extends WeakReference<ThreadLocal> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal k, Object v) { super(k); value = v; } }
<2>同時它的成員的key也一直是負責管理它的ThreadLocal物件。
好了，至此，描述一下三者之間的結構：
ThreadLocal 負責管理ThreadLocalMap，包括插入，刪除 等等，key就是ThreadLocal物件自己，同時，很重要的一點，就ThreadLocal把map儲存在當前執行緒物件裡面。看一下ThreadLocal的get，set方法就一目瞭然
get（）：
set（）：public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) return (T)e.value; } return setInitialValue(); }
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
假設 TA,TB 執行緒， 其中TA執行緒分別在 LA,LB ThreadLocal物件 分別插入 VA,VB 值物件， TB 在 LA,LC 物件中插入VA，VC 值物件，
則，TA 執行緒的ThreadLocalMap，儲存 weak-reference(LA)-VA,wr(LB)-VB 兩組值，
TB 執行緒裡的ThreadLocalMap儲存 wr(LA)-VA,wr(LC)-VC 。
為什麼在ThreadLocalMap 中弱引用ThreadLocal物件呢，當然是從執行緒記憶體管理的角度出發的。
使用弱引用，使得ThreadLocalMap知道ThreadLocal物件是否已經失效，一旦該物件失效，也就是成為垃圾，那麼它所操控的Map裡的資料也就沒有用處了，因為外界再也無法訪問，進而決定插除Map中相關的值物件，Entry物件的引用，來保證Map總是保持儘可能的小。
總之，執行緒通過ThreadLocal 來給自己的map 新增值，刪除值。同時一旦ThreadLocal本身成為垃圾，Map也能自動清除該ThreadLocal所操控的資料。
引用 /**
* Heuristically scan some cells looking for stale entries.
* This is invoked when either a new element is added, or
* another stale one has been expunged. It performs a
* logarithmic number of scans, as a balance between no
* scanning (fast but retains garbage) and a number of scans
* proportional to number of elements, that would find all
* garbage but would cause some insertions to take O(n) time.
這樣，通過設計一個代理類ThreadLocal，保證了我們只需要往Map裡面塞資料，無需擔心清除，這是普通map做不到的，
貼上jdk6的原始碼：
/**
* Expunge a stale entry by rehashing any possibly colliding entries
* lying between staleSlot and the next null slot. This also expunges
* any other stale entries encountered before the trailing null. See
* Knuth, Section 6.4
*
* @param staleSlot index of slot known to have null key
* @return the index of the next null slot after staleSlot
* (all between staleSlot and this slot will have been checked
* for expunging).
*/
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
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;
}