轉自https://www.jianshu.com/p/a1cd61fa22da
thewindkee個人總結:如果線程使用線程池或者Thread長時間不會消亡,其內部的threadLocalMap也一直存在。而thread.threadLocalMap.set(threadLocal,value)。 這裏threadLocal爲弱引用,(ThreadLocal#ThreadLocalMap#new Entry(threadLocal)產生的弱引用weakRef),value爲強引用。 Entry中弱引用key對應的threadLocal 會在gc的時候 回收,因此value對應的key會變成null.value對應的內存就無法再被訪問,已經泄露了。不過好在threadLocal中 expungeStaleEntry(threadLocal調用get/set/remove觸發) 會清除key爲null的value,一定程度解決了內存泄漏的問題。
ps:當threadLocal 不爲靜態變量,且被回收的時候纔會導致weakRef爲null。
ThreadLocal原理回顧
ThreadLocal的原理:每個Thread內部維護着一個ThreadLocalMap,它是一個Map。這個映射表的Key是一個弱引用,其實就是ThreadLocal本身,Value是真正存的線程變量Object。
也就是說ThreadLocal本身並不真正存儲線程的變量值,它只是一個工具,用來維護Thread內部的Map,幫助存和取。注意上圖的虛線,它代表一個弱引用類型,而弱引用的生命週期只能存活到下次GC前。
ThreadLocal爲什麼會內存泄漏
ThreadLocal在ThreadLocalMap中是以一個弱引用身份被Entry中的Key引用的,因此如果ThreadLocal沒有外部強引用來引用它,那麼ThreadLocal會在下次JVM垃圾收集時被回收。這個時候就會出現Entry中Key已經被回收,出現一個null Key的情況,外部讀取ThreadLocalMap中的元素是無法通過null Key來找到Value的。因此如果當前線程的生命週期很長,一直存在,那麼其內部的ThreadLocalMap對象也一直生存下來,這些null key就存在一條強引用鏈的關係一直存在:Thread --> ThreadLocalMap-->Entry-->Value,這條強引用鏈會導致Entry不會回收,Value也不會回收,但Entry中的Key卻已經被回收的情況,造成內存泄漏。
但是JVM團隊已經考慮到這樣的情況,並做了一些措施來保證ThreadLocal儘量不會內存泄漏:在ThreadLocal的get()、set()、remove()方法調用的時候會清除掉線程ThreadLocalMap中所有Entry中Key爲null的Value,並將整個Entry設置爲null,利於下次內存回收。
來看看ThreadLocal的get()方法底層實現
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();
}
在調用map.getEntry(this)時,內部會判斷key是否爲null,繼續看map.getEntry(this)源碼
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);
}
在getEntry方法中,如果Entry中的key發現是null,會繼續調用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;
}
注意k == null這裏,繼續調用了expungeStaleEntry(i)方法,expunge的意思是擦除,刪除的意思,見名知意,在來看expungeStaleEntry方法的內部實現:
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot(意思是,刪除value,設置爲null便於下次回收)
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;
}
注意這裏,將當前Entry刪除後,會繼續循環往下檢查是否有key爲null的節點,如果有則一併刪除,防止內存泄漏。
但這樣也並不能保證ThreadLocal不會發生內存泄漏,例如:
- 使用static的ThreadLocal,延長了ThreadLocal的生命週期,可能導致的內存泄漏。
- 分配使用了ThreadLocal又不再調用get()、set()、remove()方法,那麼就會導致內存泄漏。
爲什麼使用弱引用?
從表面上看,發生內存泄漏,是因爲Key使用了弱引用類型。但其實是因爲整個Entry的key爲null後,沒有主動清除value導致。很多文章大多分析ThreadLocal使用了弱引用會導致內存泄漏,但爲什麼使用弱引用而不是強引用?
官方文檔的說法:
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
爲了處理非常大和生命週期非常長的線程,哈希表使用弱引用作爲 key。
下面我們分兩種情況討論:
- key 使用強引用:引用的ThreadLocal的對象被回收了,但是ThreadLocalMap還持有ThreadLocal的強引用,如果沒有手動刪除,ThreadLocal不會被回收,導致Entry內存泄漏。
- key 使用弱引用:引用的ThreadLocal的對象被回收了,由於ThreadLocalMap持有ThreadLocal的弱引用,即使沒有手動刪除,ThreadLocal也會被回收。value在下一次ThreadLocalMap調用set,get,remove的時候會被清除。
比較兩種情況,我們可以發現:由於ThreadLocalMap的生命週期跟Thread一樣長,如果都沒有手動刪除對應key,都會導致內存泄漏,但是使用弱引用可以多一層保障:弱引用ThreadLocal不會內存泄漏,對應的value在下一次ThreadLocalMap調用set,get,remove的時候會被清除。
因此,ThreadLocal內存泄漏的根源是:由於ThreadLocalMap的生命週期跟Thread一樣長,如果沒有手動刪除對應key的value就會導致內存泄漏,而不是因爲弱引用。
總結
綜合上面的分析,我們可以理解ThreadLocal內存泄漏的前因後果,那麼怎麼避免內存泄漏呢?
- 每次使用完ThreadLocal,都調用它的remove()方法,清除數據。
在使用線程池的情況下,沒有及時清理ThreadLocal,不僅是內存泄漏的問題,更嚴重的是可能導致業務邏輯出現問題。所以,使用ThreadLocal就跟加鎖完要解鎖一樣,用完就清理。
作者:Misout
鏈接:https://www.jianshu.com/p/a1cd61fa22da
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯繫作者獲得授權並註明出處。