ThreadLocal原理解析以及是否需要調用remove方法

平常的開發過程中，如果有個類不是線程安全的，比如SimpleDateFormat，要使這個類在并發的過程中是線程安全的，那么可以將變量設置位局部變量，不過存在的問題就是頻繁的創建對象，對性能和資源會有一定降低和消耗；那么這里就可以用到ThreadLocal作為線程隔離，那么ThreadLocal是如何實現線程與線程之間隔離的呢，待會兒會在下文進行講解。

之前有篇使用ThreadLocal做線程之間的隔離實例，大家可以參考一下：使用ThreadLocal實現Mybatis多數據源

JDK引用類型

在了解ThreadLocal原理之前，先讓大家了解一下JDK中的引用類型。

JDK共有四種引用類型：

1、強引用類型：就是平常創建的對象都屬于強引用類型，比如 Object object = new Object();該object為強引用類型，如果該引用沒有主動置為null，那么該引用的對象就不會被GC回收，所以一般在寫完一段業務之后都會將用到的對象引用置為null，就是為了輔助GC更好的進行垃圾回收。

2、軟引用類型：比強引用的類型弱一點，在應用程序發生OOM（內存溢出）之前就會去回收這些弱引用占用的內存，使用的SoftReference類，使用示例如下：

?3、弱引用類型：比軟引用類型還要弱一點，在下一次發生GC回收之前就會被垃圾回收器進行回收，使用WeakReference類，使用示例如下：

4、虛引用類型：這個是JDK中最弱的引用類型，在對象被回收之前會移入到一個隊列當中，然后在進行刪除，這個引用類型用的不多，在JDK中引用的類是PhantomReference，這個需結合引用隊列（ReferenceQueue）以及重寫finalize方法進行使用，使用示例如下：

?對于應用場景來說，如果當前對象為可有可無的話，那么可以使用軟引用或者弱引用進行使用，而對應虛引用的話，個人認為可以適用在非GC回收的區域（比如：元空間MetaSpace）使用，可以用來監測這些區域的回收情況等。

基本原理

ThreadLocal的用法呢，這里就先不談；底層使用的是ThreadLocalMap這個Map的底層采用的是ThreadLocalMap.Entry，ThreadLocalMap這個類在每個線程當中都會存在一份對應的單獨得對象，在Thread類中變量如下：

? ? /* ThreadLocal values pertaining to this thread. This map is maintained
? ? ?* by the ThreadLocal class. */
? ? ThreadLocal.ThreadLocalMap threadLocals = null;

這里就是線程安全的重點，因為并發的情況下，每個線程都對應著有份自己的ThreadLocalMap，所以就不存在多線程競爭資源問題，所以如果使用ThreadLocal建議和線程一起使用，以為這樣可以減少系統的性能開銷以及對ThreadLocal對象的一種復用，提升系統性能。

看一下ThreadLocalMap，會發現Entry繼承了WeakReference類，說明這個類創建出來的對象是弱引用對象

static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}
}
//容量
private static final int INITIAL_CAPACITY = 16;
//存儲屬性值
private Entry[] table;
//構造初始化table數組
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {table = new Entry[INITIAL_CAPACITY];int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);table[i] = new Entry(firstKey, firstValue);size = 1;setThreshold(INITIAL_CAPACITY);
}

我們開看一下get方法：獲取當前線程，然后通過調用getMap方法獲取到當前線程的ThreadLocalMap對象，對于剛開始初始化的線程或者在ThreadLocalMap中沒有找到來說，那么就會走下面的setInitialValue方法，如果已經初始化的ThreadLocalMap來說，會直接獲取對應的Entry對象

    /*** Returns the value in the current thread's copy of this* thread-local variable.  If the variable has no value for the* current thread, it is first initialized to the value returned* by an invocation of the {@link #initialValue} method.** @return the current thread's value of this thread-local*/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();}

在setInitialValue方法中，會發現去獲取初始化方法中的對象，如果在創建ThreadLocal沒有重寫初始化方法的話，那么就會返回null，或者在使用前調用set方法重新設置一下當前線程中的ThreadLocalMap中的屬性初始化值，大家可以各自去看一下set方法；

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

這里列一下getEntry方法，根據ThreadLocal對象計算出hash值找到對應的table數組的位置，并且獲取到這個對象。

private Entry getEntry(ThreadLocal<?> key) {int i = key.threadLocalHashCode & (table.length - 1);Entry e = table[i];if (e != null && e.get() == key)return e;elsereturn getEntryAfterMiss(key, i, e);
}

問題

以為這就完了？并沒有，規范的使用為在使用過get方法應該在調用remove方法進行刪除（即將當前線程ThreadLocalMap中的引用置為空并且table數組中的Entry值也置為空）；如果是線程池的話，那么這些數據就會一直存在，如果沒有及時刪除會造成內存泄漏。

調用remove方法回去執行ThreadLocalMap的remove方法，而在這個方法中，通過計算得到對應的Entry數組的位置，并且進行引用清除以及table數組清空，避免內存泄漏問題，

public void remove() {ThreadLocalMap m = getMap(Thread.currentThread());if (m != null)m.remove(this);
}
/*** Remove the entry for key.*/
private void remove(ThreadLocal<?> key) {Entry[] tab = table;int len = tab.length;int i = key.threadLocalHashCode & (len-1);for (Entry e = tab[i];e != null;e = tab[i = nextIndex(i, len)]) {if (e.get() == key) {//將Entry本身的引用ThreadLocal置為空e.clear();//清空table數組中Entry.valueexpungeStaleEntry(i);return;}}
}

但是如果是經常性用到的ThreadLocal的話，個人建議可以不用刪除，因為如果頻繁使用的話，置為null，后面又會重新調用在ThreadLocalMap未找到，那么就會調用setInitialValue方法，重新創建對象并且賦值，在某種意義上可以說是和局部變量是一樣的了，這樣就違背了當初減少性能開銷的需求了。

在加上Entry繼承了WeakReference類，所以創建的對象會是個弱引用類型，在GC進行回收時候會被回收掉的，如果回收掉了引用對象，那么Entry中的value變量值是否還存在呢；

繼續解析

注意這里是回收掉引用的對應，即ref.get()為null值，但是弱引用本身這個對象是還在的，我們看一下在setInitialValue方法中是如何處理的，重新設置里面，如果獲取到ThreadLocal引用沒有獲取到，說明這個弱引用被回收了，這里就會去調用replaceStaleEntry方法。

private T setInitialValue() {T value = initialValue();Thread t = Thread.currentThread();ThreadLocalMap map = getMap(t);if (map != null)map.set(this, value);//重新設置值elsecreateMap(t, value);return value;
}
//ThreadLocalMapprivate void set(ThreadLocal<?> key, Object value) {Entry[] tab = table;int len = tab.length;int i = key.threadLocalHashCode & (len-1);for (Entry e = tab[i];e != null;e = tab[i = nextIndex(i, len)]) {ThreadLocal<?> k = e.get();if (k == key) {e.value = value;return;}if (k == null) {replaceStaleEntry(key, value, i);return;}}tab[i] = new Entry(key, value);int sz = ++size;if (!cleanSomeSlots(i, sz) && sz >= threshold)rehash();
}

?而在replaceStaleEntry方法中有個這么一行代碼，將value變量置為null并且重新創建Entry對象，所以就算是沒有調用remove刪除方法，在GC過后依舊會置為null。

? ? ? ? ? ? // If key not found, put new entry in stale slot
? ? ? ? ? ? tab[staleSlot].value = null;
? ? ? ? ? ? tab[staleSlot] = new Entry(key, value);

在此會有個小問題，為啥不用SoftReference而是使用WeakReference，個人覺得如果使用軟引用的話，如果是使用線程池并且ThreadLocal會頻繁訪問的話，那么是可以的，但是實際應用并非只有這種情況，而且在發生OOM之前，只會回收掉軟引用對象，但是Entry中的value變量還在，并不能真正的回收掉值，只有等到下一次使用的時候才能置為null，所以綜合來看使用WeakReference還是最好的選擇。

歡迎各位大佬一起討論