WeakReference 學習和使用

本文轉自：http://qifuguang.me/2015/09/02/[Java%E5%B9%B6%E5%8F%91%E5%8C%85%E5%AD%A6%E4%B9%A0%E4%B8%83]%E8%A7%A3%E5%AF%86ThreadLocal/
這里也留着以后自己方便再看。

相信讀者在網上也看了很多關於ThreadLocal的資料，很多博客都這樣說：ThreadLocal為解決多線程程序的並發問題提供了一種新的思路，ThreadLocal的目的是為了解決多線程訪問資源時的共享問題，balabala的。錯，大錯特錯！

ThreadLocal的源碼注釋，翻譯過來大概是這樣的：

ThreadLocal類用來提供線程內部的局部變量。這種變量在多線程環境下訪問(通過get或set方法訪問)時能保證各個線程里的變量相對獨立於其他線程內的變量。ThreadLocal實例通常來說都是private static類型的，用於關聯線程和線程的上下文。

可以總結為一句話：ThreadLocal的作用是提供線程內的局部變量，這種變量在線程的生命周期內起作用，減少同一個線程內多個函數或者組件之間一些公共變量的傳遞的復雜度。

舉個栗子，我出門需要先坐公交再做地鐵，這里的坐公交和坐地鐵就好比是同一個線程內的兩個函數，我就是一個線程，我要完成這兩個函數都需要同一個東西：公交卡（北京公交和地鐵都使用公交卡），那么我為了不向這兩個函數都傳遞公交卡這個變量（相當於不是一直帶着公交卡上路），我可以這么做：將公交卡事先交給一個機構，當我需要刷卡的時候再向這個機構要公交卡（當然每次拿的都是同一張公交卡）。這樣就能達到只要是我(同一個線程)需要公交卡，何時何地都能向這個機構要的目的。

有人要說了：你可以將公交卡設置為全局變量啊，這樣不是也能何時何地都能取公交卡嗎？但是如果有很多個人（很多個線程）呢？大家可不能都使用同一張公交卡吧(我們假設公交卡是實名認證的)，這樣不就亂套了嘛。現在明白了吧？這就是ThreadLocal設計的初衷：提供線程內部的局部變量，在本線程內隨時隨地可取，隔離其他線程，為了方便！

接下來我們看看ThreadLocal內部的實現原理，如果給你，你會怎么設計。相信大部分人會有這樣的想法：

每個ThreadLocal類創建一個Map，然后用線程的ID作為Map的key，實例對象作為Map的value，這樣就能達到各個線程的值隔離的效果。

沒錯，這是最簡單的設計方案，JDK最早期的ThreadLocal就是這樣設計的。JDK1.3（不確定是否是1.3）之后ThreadLocal的設計換了一種方式。

我們先看看JDK8的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) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }

其中getMap的源碼：

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals; }

setInitialValue函數的源碼：

private T setInitialValue() { T value = initialValue(); Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); return value; }

createMap函數的源碼：

void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); }

簡單解析一下，get方法的流程是這樣的：

1、首先獲取當前線程；
2、根據當前線程獲取一個Map；
3、如果獲取的Map不為空，則在Map中以ThreadLocal的引用作為key來在Map中獲取對應的value e，否則轉到5；
4、如果e不為null，則返回e.value，否則轉到5；
5、Map為空或者e為空，則通過initialValue函數獲取初始值value，然后用ThreadLocal的引用和value作為firstKey和firstValue創建一個新的Map。

然后需要注意的是Thread類中包含一個成員變量：

ThreadLocal.ThreadLocalMap threadLocals = null;

所以，可以總結一下ThreadLocal的設計思路：

每個Thread維護一個ThreadLocalMap映射表，這個映射表的key是ThreadLocal實例本身，value是真正需要存儲的Object。

這個方案剛好與我們開始說的簡單的設計方案相反。查閱了一下資料，這樣設計的主要有以下幾點優勢：

1、這樣設計之后每個Map的Entry數量變小了：之前是Thread的數量，現在是ThreadLocal的數量，能提高性能，據說性能的提升不是一點兩點(沒有親測)。
2、當Thread銷毀之后對應的ThreadLocalMap也就隨之銷毀了，能減少內存使用量。

再深入一點

先交代一個事實：ThreadLocalMap是使用ThreadLocal的弱引用作為Key的：

static class ThreadLocalMap { /** * The entries in this hash map extend WeakReference, using * its main ref field as the key (which is always a * ThreadLocal object). Note that null keys (i.e. entry.get() * == null) mean that the key is no longer referenced, so the * entry can be expunged from table. Such entries are referred to * as "stale entries" in the code that follows. */ static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } } ... ... }

下圖是本文介紹到的一些對象之間的引用關系圖，實線表示強引用，虛線表示弱引用：

然后網上就傳言，ThreadLocal會引發內存泄露，他們的理由是這樣的：

如上圖，ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用引用他，那么系統gc的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前線程再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value
永遠無法回收，造成內存泄露。

我們來看看到底會不會出現這種情況。

其實，在JDK的ThreadLocalMap的設計中已經考慮到這種情況，也加上了一些防護措施，下面是ThreadLocalMap的getEntry方法的源碼：

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); }

getEntryAfterMiss函數的源碼：

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; }

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(); 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; }

整理一下ThreadLocalMap的getEntry函數的流程：

1. 首先從ThreadLocal的直接索引位置(通過ThreadLocal.threadLocalHashCode & (len-1)運算得到)獲取Entry e，如果e不為null並且key相同則返回e；

2. 如果e為null或者key不一致則向下一個位置查詢，如果下一個位置的key和當前需要查詢的key相等，則返回對應的Entry，否則，如果key值為null，則擦除該位置的Entry，否則繼續向下一個位置查詢。

在這個過程中遇到的key為null的Entry都會被擦除，那么Entry內的value也就沒有強引用鏈，自然會被回收。仔細研究代碼可以發現，set操作也有類似的思想，將key為null的這些Entry都刪除，防止內存泄露。

但是光這樣還是不夠的，上面的設計思路依賴一個前提條件：要調用ThreadLocalMap的getEntry函數或者set函數。這當然是不可能任何情況都成立的，所以很多情況下需要使用者手動調用ThreadLocal的remove函數，手動刪除不再需要的ThreadLocal，防止內存泄露。所以JDK建議將ThreadLocal變量定義成private static的，這樣的話ThreadLocal的生命周期就更長，由於一直存在ThreadLocal的強引用，所以ThreadLocal也就不會被回收，也就能保證任何時候都能根據ThreadLocal的弱引用訪問到Entry的value值，然后remove它，防止內存泄露。