阿粉昨天說我動不動就內存泄漏，我好委屈...

https://mp.weixin.qq.com/s/DkgYoM1UK2vAOFQHIihRKA

天天早上七點三十，準時推送乾貨

你們好，我是 ThreadLocal ，昨天阿粉說我動不動就內存泄漏，我蠻委屈的，我纔沒有冤枉他嘞，證據在這裏： ThreadLocal 你怎麼動不動就內存泄漏？

由於人家明明也考慮到了不少狀況，作了不少事情，保證了若是沒有 remove ，也有對 key 值爲 null 時進行回收的處理操做

啥？你居然不信？我 ThreadLocal 難道會騙你麼

今天爲了證實一下本身，我打算從組成的源碼開始講起，在 get ， set 方法中都有對 key 值爲 null 時進行回收的處理操做，先來看 set 方法是怎麼作的

set

下面是 set 方法的源碼：

private void set(ThreadLocal<?> key, Object value) {

    // We don't use a fast path as with get() because it is at
    // least as common to use set() to create new entries as
    // it is to replace existing ones, in which case, a fast
    // path would fail more often than not.

    Entry[] tab = table;
    int len = tab.length;
    int i = key.threadLocalHashCode & (len-1);

    for (Entry e = tab[i];
        // 若是 e 不爲空,說明 hash 衝突,須要向後查找
        e != null;
        // 從這裏能夠看出, ThreadLocalMap 採用的是開放地址法解決的 hash 衝突
        // 是最經典的 線性探測法 --> 我以爲之因此選擇這種方法解決衝突時由於數據量不大
        e = tab[i = nextIndex(i, len)]) {
        ThreadLocal<?> k = e.get();

        // 要查找的 ThreadLocal 對象找到了,直接設置須要設置的值,而後 return
        if (k == key) {
            e.value = value;
            return;
        }

        // 若是 k 爲 null ,說明有 value 沒有及時回收,此時經過 replaceStaleEntry 進行處理
        // replaceStaleEntry 具體內容等下分析
        if (k == null) {
            replaceStaleEntry(key, value, i);
            return;
        }
    }

    // 若是 tab[i] == null ,則直接建立新的 entry 便可
    tab[i] = new Entry(key, value);
    int sz = ++size;
    // 在建立以後調用 cleanSomeSlots 方法檢查是否有 value 值沒有及時回收
    // 若是 sz >= threshold ,則須要擴容,從新 hash 即, rehash();
    if (!cleanSomeSlots(i, sz) && sz >= threshold)
        rehash();
}

經過源碼能夠看到，在 set 方法中，主要是經過 replaceStaleEntry 方法和 cleanSomeSlots 方法去作的檢測和處理

接下來瞅瞅 replaceStaleEntry 都幹了點兒啥

replaceStaleEntry

private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                                int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;
    Entry e;

    // 從當前 staleSlot 位置開始向前遍歷
    int slotToExpunge = staleSlot;
    for (int i = prevIndex(staleSlot, len);
        (e = tab[i]) != null;
        i = prevIndex(i, len))
        if (e.get() == null)
            // 當 e.get() == null 時, slotToExpunge 記錄下此時的 i 值
            // 即 slotToExpunge 記錄的是 staleSlot 左手邊第一個空的 Entry
            slotToExpunge = i;

    // 接下來從當前 staleSlot 位置向後遍歷
    // 這兩個遍歷是爲了清理在左邊遇到的第一個空的 entry 到右邊的第一個空的 entry 之間全部過時的對象
    // 可是若是在向後遍歷過程當中,找到了須要設置值的 key ,就開始清理,不會再繼續向下遍歷
    for (int i = nextIndex(staleSlot, len);
        (e = tab[i]) != null;
        i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();

        // 若是 k == key 說明在插入以前就已經有相同的 key 值存在,因此須要替換舊的值
        // 同時和前面過時的對象進行交換位置
        if (k == key) {
            e.value = value;

            tab[i] = tab[staleSlot];
            tab[staleSlot] = e;

            // 若是 slotToExpunge == staleSlot 說明向前遍歷時沒有找到過時的
            if (slotToExpunge == staleSlot)
                slotToExpunge = i;
            // 進行清理過時數據
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
            return;
        }

        // 若是在向後遍歷時,沒有找到 value 被回收的 Entry 對象
        // 且剛開始 staleSlot 的 key 爲空,那麼它自己就是須要設置 value 的 Entry 對象
        // 此時不涉及到清理
        if (k == null && slotToExpunge == staleSlot)
            slotToExpunge = i;
    }

    // 若是 key 在數組中找不到,那就好說了,直接建立一個新的就能夠了
    tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

    // 若是 slotToExpunge != staleSlot 說明存在過時的對象,就須要進行清理
    if (slotToExpunge != staleSlot)
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

在 replaceStaleEntry 方法中,須要注意一下剛開始的兩個 for 循環中內容（在這裏再貼一下）：

if (e.get() == null)
    // 當 e.get() == null 時, slotToExpunge 記錄下此時的 i 值
    // 即 slotToExpunge 記錄的是 staleSlot 左手邊第一個空的 Entry
    slotToExpunge = i;

if (k == key) {
    e.value = value;

    tab[i] = tab[staleSlot];
    tab[staleSlot] = e;
                                        
    // 若是 slotToExpunge == staleSlot 說明向前遍歷時沒有找到過時的
    if (slotToExpunge == staleSlot)
        slotToExpunge = i;
        // 進行清理過時數據
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        return;
}

這兩個 for 循環中的 if 究竟是在作什麼？

看第一個 if ，當 e.get() == null 時，此時將 i 的值給 slotToExpunge

第二個 if ，當 k ==key 時，此時將 i 給了 staleSlot 來進行交換

爲何要對 staleSlot 進行交換呢？畫圖說明一下

以下圖，假設此時表長爲 10 ，其中下標爲 3 和 5 的 key 已經被回收（ key 被回收掉的就是 null ），由於採用的開放地址法，因此 15 mod 10 應該是 5 ，可是由於位置被佔，因此在 6 的位置，一樣 25 mod 10 也應該是 5 ，可是由於位置被佔，下個位置也被佔，因此就在第 7 號的位置上了

按照上面的分析，此時 slotToExpunge 值爲 3 ， staleSlot值爲 5 ， i 爲 6

假設，假設這個時候若是不進行交換，而是直接回收的話，此時位置爲 5 的數據就被回收掉，而後接下來要插入一個 key 爲 15 的數據，此時 15 mod 10 算出來是 5 ，正好這個時候位置爲 5 的被回收完畢，這個位置就被空出來了，那麼此時就會這樣：

一樣的 key 值居然出現了兩次？！

這確定是不但願看到的結果，因此必定要進行數據交換

在上面代碼中有一行代碼 cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); ，說明接下來的處理是交給了 expungeStaleEntry ，接下來去分析一下 expungeStaleEntry

expungeStaleEntry

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();
        // 若是 k == null ,說明 value 就應該被回收掉
        if (k == null) {
            // 此時直接將 e.value 置爲 null 
            // 這樣就將 thread -> threadLocalMap -> value 這條引用鏈給打破
            // 方便了 GC
            e.value = null;
            tab[i] = null;
            size--;
        } else {
            // 這個時候要從新 hash ,由於採用的是開放地址法,因此能夠理解爲就是將後面的元素向前移動
            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;
}

由於是在 replaceStaleEntry 方法中調用的此方法，傳進來的值是 staleSlot ，繼續上圖，通過 replaceStaleEntry 以後，它的數據結構是這樣：

此時傳進來的 staleSlot 值爲 6 ，由於此時的 key 爲 null ，因此接下來會走 e.value = null ，這一步結束以後，就成了：

接下來 i 爲 7 ，此時的 key 不爲 null ，那麼就會從新 hash : int h = k.threadLocalHashCode & (len - 1); ，獲得的 h 應該是 5 ，可是實際上 i 爲 7 ，說明出現了 hash 衝突，就會繼續向下走，最終的結果是這樣：

能夠看到，原來的 key 爲 null ，值爲 V5 的已經被回收掉了。我認爲之因此回收掉以後，還要再次進行從新 hash ，就是爲了防止 key 值重複插入狀況的發生

假設 key 爲 25 的並無進行向前移動，也就是它還在位置 7 ，位置 6 是空的，再插入一個 key 爲 25 ，通過 hash 應該在位置 5 ，可是有數據了，那就向下走，到了位置 6 ，誒，居然是空的，趕忙插進去，這不就又形成了上面說到的問題，一樣的一個 key 居然出現了兩次？！

並且通過 expungeStaleEntry 以後，將 key 爲 null 的值，也設置爲了 null ，這樣就方便 GC

分析到這裏應該就比較明確了，在 expungeStaleEntry 中，有些地方是幫助 GC 的，而經過源碼可以發現， set 方法調用了該方法進行了 GC 處理， get 方法也有，不信你瞅瞅：

get

private Entry getEntry(ThreadLocal<?> key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    // 若是可以找到尋找的值,直接 return 便可
    if (e != null && e.get() == key)
        return e;
    else
        // 若是找不到,則調用 getEntryAfterMiss 方法去處理
        return 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)
            // 若是 k == null 說明有 value 沒有及時回收
            // 調用 expungeStaleEntry 方法去處理,幫助 GC
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

get 和 set 方法都有進行幫助 GC ，因此正常狀況下是不會有內存溢出的，可是若是建立了以後一直沒有調用 get 或者 set 方法，仍是有可能會內存溢出

因此最保險的方法就是，使用完以後就及時 remove 一下，加快垃圾回收，就完美的避免了垃圾回收

我 ThreadLocal 雖然沒辦法作到 100% 的解決內存泄漏問題，可是我能作到 80% 不也應該誇誇我嘛

Java極客技術 發起了一個讀者討論歡迎留言吐槽精選討論內容參與討論

poker

上面set函數裏面的for循環註釋寫的不對，實際上是由於用了開放定址法解決衝突，因此在set的時候，以第一個非空的entry做爲起始條件，以entry爲空做爲終止條件，而後逐個比較key是否和參數對應

< END >