先給出結論：get，set兩個方法都不能完全防止記憶體洩漏，還是每次用完ThreadLocal都勤奮的remove一下靠譜。 

  前言： 

  看到有的部落格說在把ThreadLocal的所有強引用置空前，呼叫 set 或 get 方法的話，則可以防止這個失去所有強引用的ThreadLocal對應的value記憶體洩漏。  但是文章作者一般沒有接著向下講為什麼get，set 方法能防止記憶體洩漏。 

  本著刨根問底的精神，我們來看看原實現，驗證一下get，set方法是否真的能防止記憶體洩漏。

先介紹一下記憶體佈局：

  每個Thread儲存自己獨佔的ThreadLocalMap，ThreadLocalMap包含一個散列表（entry陣列），散列表裡 entry 繼承WeakReference<ThreadLocal>，並且 entry 的 key 隱式等於ThreadLocal， value 則是顯示用成員變數來儲存。

所以一個執行緒可以用不同的ThreadLocal把不同的值存在這個執行緒獨享的散列表的不同位置上。下面這些entry的key就是不同的ThreadLocal。當有外部的強引用 使用ThreadLocal的時候，這個ThreadLocal是有效的，但是如果強引用都置空，則只剩弱引用，GC在記憶體緊張的情況下，可能會把弱引用指向的物件回收掉。

1.ThreadLocal還有效

2.ThreadLocal只剩下弱引用

3.只剩弱引用，回收堆上物件

這樣的話，就沒有路徑可以訪問這個ThreadLocal了。

但是value還是通過ThreadLocalMap -> entry -> value -> 堆上大物件 的方式強應用著之前的value。這樣導致這塊記憶體無法被使用（如果沒有其他強應用的話），也無法被回收。稱記憶體洩漏。

於是ThreadLocalMap的設計者，想出了辦法：

1.在ThreadLocal get，set 的時候順帶把散列表中的無效entry 置空，並且把這些entry 的 value也置空，以便value被回收，也就是執行清掃操作

2.在ThreadLocal remove 的時候把對應槽位上的 entry 置空，並且把這 個entry 的 value也置空，以便value被回收。順便執行清掃操作。

get，set 方法真的能保證記憶體不洩露麼？

這篇文章想討論的問題是：

1.get，set方法的清掃程度是否足夠徹底，以至於可以防止記憶體洩漏。

2.用什麼方法才能保證記憶體不洩露

1如果成立，也即是保證如下場景記憶體不洩露：

使用多個 ThreadLocal，不是每次都使用 remove 方法，並且把一個ThreadLocal對應的所有強應用置空之前只調用過 get, set方法，呼叫get，set方法可以防止記憶體洩漏。

為了打破這一假設，模擬記憶體洩漏的情況，舉以下極端的例子：

先規定：

1.一開始都是有效的entry，並且每個entry的key通過雜湊演算法後算出的位置都是自己所在的位置（都在自己的位置上的話之後的線性清掃中不會造成搬移，因為ThreadLocalMap的散列表用的是開放定址法，所以entry可能因為hash衝突而不在自己位置上）

要達成下面的效果，就要一直沒有失效的entry出現，並且一直實現插入，也就是一直執行set方法

假設entry陣列有32個槽位

如果執行一次remove，把圖中的某個entry無效化。

 下面是實現，因為每個entry都在自己的位置上，所以下圖的if (e.get() == key) 會在第一個迴圈就成立，也就是remove會

 執行e.clear() 來把弱引用置空，無效化。並且執行一次線性清掃後返回。

關於線性清掃：

　　實現較長，分段看：

　　上來就把要清掃的位置給置空了（灰色entry的槽位置空）：

接著看：

 向後遍歷整個陣列，直到遇到空槽為止，並且第一種情況 (k == null) 為真的情況下，會把無效entry置空，防止記憶體洩漏。

 其實就是向後掃描，遇到無效的就順帶幹掉，直到遇到空位置為止。

 第二種情況是 ： 遇到的entry是有效的，但是不是在自己原本的位置上，而是被hash衝突所迫而在其他位置上的，則把他們搬去

 離原本位置最近的後邊空槽上。這樣在get的時候，會最快找到這個entry，減少開放定址法遍歷陣列的時間。

 因為每個entry都在自己的位置上，並且沒有遇到無效的entry，最終的效果只是把remove的位置置為空槽。

同理，經過幾次remove後，我們可以“挖出”下圖的效果

正巧，這時候有兩個entry的key，也即是ThreadLocal的所有強應用被置空，於是這兩個entry無效。

如果之後只執行 set 方法，是否會記憶體洩漏呢？是否任意呼叫set之後就保證記憶體不會洩漏了呢？

我們順著 set 方法的邏輯看下去，set方法從當前要set的位置開始向後遍歷，直到：

1.遇到 key 和我們當前 呼叫 set 的 ThreadLocal 相等的 entry，則只用直接把entry的value設定以下就好了，和

HashMap的 put(1, A); put(1, B); 中 A 被替換 成B 同理。（紅色框）

2.遇到無效entry，是我們關注的地方。

3.遇到空槽，直接插入，並且嘗試指數清掃，如果指數清掃不成功並且當前entry的使用槽數到達閾值則重雜湊（藍色框）

我們重點關注情況2.

假設我們set的位置是下面所指處。

我們接著上面的2分析，2要呼叫到replaceStaleEntry

再假設set進去的ThreadLocal在本陣列中下面綠色位置

綠色代表這個entry不在自己的原本位置上，上面的情況是可以得到的。因為remove時執行的線性清掃是向後清掃，並且遇到空槽停下。

所以不會影響綠色entry

 方法一開始是找到最靠前的無效entry，直到遇到空槽為止，當然可能會繞陣列一圈繞回來

但是因為使用的槽數如果到達閾值，就會rehash，不可能所有槽都用完。所以會遇到空槽的。

表現在我們的例子中：

因為沒有找到，所以 slotToExpunge = staleSlot

也就是上圖第二個灰色entry的位置。

 接著向下看：

 我們關注 k == key 的情況，也就是 i 遍歷圖中綠色槽位的情況。 這種情況下會指向一次線性清掃，然後執行對數清掃。之後返回。

反應在圖例中：

從slotToExpunge位置開始，先進行一輪線性清掃：

同之前一樣，一上來先把待清掃槽位置空（第二個灰色的entry的位置），之後遇到第二個灰色後面那個空位，所以停下來。

線性清掃返回空位的下標做為引數傳給對數清掃。

反應到圖例：

對數清掃：清掃次數 = log2（N） ，N是散列表大小，本例中是32，所以要清掃5次，每次清掃是通過呼叫線性清掃實現的。

並且只有遇到無效entry時才執行線性清掃。

 顯然，五次掃描中都沒有無效entry

返回 removed (false);

 cleanSomeSlots要返回，一直返回到replaceStaleEntry,並且繼續返回，最後從set方法返回。

 結果很明顯，第一個灰色entry未被清除。

結論：set方法的清掃程度不夠深，set方法並不能防止記憶體洩漏。

get方法呢？

 get 方法比較簡單，在原本屬於當前 key 的位置上找不到當前 key 的 entry 的話，就會根據開放定址法線性遍歷找到 key 對應的 entry 。

順便把路上無效的entry用線性清掃清除掉。

還是剛剛的極端例子：

 因為是直接取線性清掃開始的位置，所以 k = key 是 true，所以返回綠色entry。查詢成功

 但是，第一個灰色entry仍然沒有被清除。

 什麼辦法可以保證萬無一失呢？？？

答：每次置空一個ThreadLocal的所有強引用之後，都呼叫ThreadLocal的remove方法：

e.clear是直接置空弱引用，這樣當前這個entry就會無效

之前說過，線性清掃會直接把第一個無效entry，也就是起點的entry槽位置空，以此達到 100 % 的回收效果。

結論：

get，set兩個方法都不能完全防止記憶體洩漏，還是每次用完ThreadLocal都勤奮的remove一下靠譜。

 &n