java 深入理解ThreadLocal__java

相信讀者在網上也看了很多關於ThreadLocal的資料，很多部落格都這樣說：ThreadLocal為解決多線程程式的並發問題提供了一種新的思路；ThreadLocal的目的是為瞭解決多線程訪問資源時的共用問題。如果你也這樣認為的，那現在給你10秒鐘，清空之前對ThreadLocal的錯誤的認知。

看看JDK中的源碼是怎麼寫的：

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its
{@code get} or {@code set} method) has its own, independently initialized copy of the variable. {@code ThreadLocal} instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).
翻譯過來大概是這樣的(英文不好，如有更好的翻譯，請留言說明)：

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

可以總結為一句話：ThreadLocal的作用是提供線程內的局部變數，這種變數線上程的生命週期內起作用，減少同一個線程內多個函數或者組件之間一些公開變數的傳遞的複雜度。
舉個例子，我出門需要先坐公交再做地鐵，這裡的坐公交和坐地鐵就好比是同一個線程內的兩個函數，我就是一個線程，我要完成這兩個函數都需要同一個東西：公交卡（北京公交和地鐵都使用公交卡），那麼我為了不向這兩個函數都傳遞公交卡這個變數（相當於不是一直帶著公交卡上路），我可以這麼做：將公交卡事先交給一個機構，當我需要刷卡的時候再向這個機構要公交卡（當然每次拿的都是同一張公交卡）。這樣就能達到只要是我(同一個線程)需要公交卡，何時何地都能向這個機構要的目的。

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

建構函式

ThreadLocal的建構函式簽章是這樣的：

/**
* Creates a thread local variable.
* @see #withInitial(java.util.function.Supplier)
*/
public ThreadLocal() {
}
內部啥也沒做。 initialValue函數

initialValue函數用來設定ThreadLocal的初始值，函數簽名如下：

protected T initialValue() {
return null;
}
該函數在調用get函數的時候會第一次調用，但是如果一開始就調用了set函數，則該函數不會被調用。通常該函數只會被調用一次，除非手動調用了remove函數之後又調用get函數，這種情況下，get函數中還是會調用initialValue函數。該函數是protected類型的，很顯然是建議在子類重載該函數的，所以通常該函數都會以匿名內部類的形式被重載，以指定初始值，比如：

package com.winwill.test;/** * @author qifuguang * @date 15/9/2 00:05 */public class TestThreadLocal {    private static final ThreadLocal<Integer> value = new ThreadLocal<Integer>() {        @Override        protected Integer initialValue() {            return Integer.valueOf(1);        }    };}

get函數

該函數用來擷取與當前線程關聯的ThreadLocal的值，函數簽名如下：

public T get()
如果當前線程沒有該ThreadLocal的值，則調用initialValue函數擷取初始值返回。 set函數

set函數用來設定當前線程的該ThreadLocal的值，函數簽名如下：

public void set(T value)
設定當前線程的ThreadLocal的值為value。 remove函數

remove函數用來將當前線程的ThreadLocal綁定的值刪除，函數簽名如下：

public void remove()
在某些情況下需要手動調用該函數，防止記憶體泄露。 代碼示範

學習了最基本的操作之後，我們用一段代碼來示範ThreadLocal的用法，該例子實現下面這個情境：

有5個線程，這5個線程都有一個值value，初始值為0，線程運行時用一個迴圈往value值相加數字。

代碼實現：

package com.winwill.test;/** * @author qifuguang * @date 15/9/2 00:05 */public class TestThreadLocal {    private static final ThreadLocal<Integer> value = new ThreadLocal<Integer>() {        @Override        protected Integer initialValue() {            return 0;        }    };    public static void main(String[] args) {        for (int i = 0; i < 5; i++) {            new Thread(new MyThread(i)).start();        }    }    static class MyThread implements Runnable {        private int index;        public MyThread(int index) {            this.index = index;        }        public void run() {            System.out.println("線程" + index + "的初始value:" + value.get());            for (int i = 0; i < 10; i++) {                value.set(value.get() + i);            }            System.out.println("線程" + index + "的累加value:" + value.get());        }    }}

執行結果為：

線程0的初始value:0
線程3的初始value:0
線程2的初始value:0
線程2的累加value:45
線程1的初始value:0
線程3的累加value:45
線程0的累加value:45
線程1的累加value:45
線程4的初始value:0
線程4的累加value:45

可以看到，各個線程的value值是相互獨立的，本線程的累加操作不會影響到其他線程的值，真正達到了線程內部隔離的效果。

如何?的

看了基本介紹，也看了最簡單的效果示範之後，我們更應該好好研究下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。
這個方案剛好與我們開始說的簡單的設計方案相反。查閱了一下資料，這樣設計的主要有以下幾點優勢： 這樣設計之後每個Map的Entry數量變小了：之前是Thread的數量，現在是ThreadLocal的數量，能提高效能，據說效能的提升不是一點兩點(沒有親測) 當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函數的流程：

首先從ThreadLocal的直接索引位置(通過ThreadLocal.threadLocalHashCode & (len-1)運算得到)擷取Entry e，如果e不為null並且key相同則返回e；
如果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它，防止記憶體泄露。 Web伺服器中線程池的狀態問題

Web服務在建立線程的過程中，頻繁的建立線程對系能的影響巨大，故很多伺服器都採用了線程池的方式來解決線程不斷建立鎖導致的問題，所以在使用線程池的過程中，由於線程是不斷的回收和利用故ThreadLocal在伺服器中也是被反覆利用的，在使用中如果不進行清查操作，很容易導致變數汙染。儘管對於很多伺服器來說，ThreadLocal是的確是相對於每個線程，每個線程會有自己的ThreadLocal。但考慮到伺服器都會維護一套線程池。因此，不同使用者訪問，可能會接受到同樣的線程。因此，在做基於TheadLocal時，需要謹慎，避免出現ThreadLocal變數的緩衝，導致其他線程訪問到本線程變數，如果運用不當，會導致系統效率低下，舉個例子，假設我們得系統在訪問的時候在ThreadLocal中加入變數不予以更新和刪除，則這個儲存的對象就變成一個增量的容器物件，如果訪問量巨大，將導致jvm記憶體不足而頻繁觸發gc，gc在工作的時候會進行資料複製，頻繁的觸發gc對系統的效能會帶來不利影響，同時還有可能導致記憶體溢出。 遇到的問題

public class ContextHolder {    private static ThreadLocal<UserContext> userContext = new InheritableThreadLocal<UserContext>();    public static UserContext getUserContext(){        if(userContext.get() == null){            userContext.set(new UserContext());        }        return userContext.get();    }    public static void setContext(UserContext context) {        userContext.set(context);    }    public static void clear(){        userContext.remove();    }}

如果每個線程（訪問請求）在結束的時候沒有調用clear 方法的時候，其他線程再訪問，就會造成線程汙染，即拿到了其他線程的變數。

參考：
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/
http://blog.csdn.net/chichengit/article/details/7994712
http://blog.csdn.net/lufeng20/article/details/24314381
http://www.importnew.com/22039.html
http://www.importnew.com/22046.html