ThreadLocal

ThreadLocal 有個內部類ThreadLocalMap，Thread中保有一個ThreadLocalMap作爲成員變量。

ThreadLocal.get/set,其實是拿到當前Thread中的ThreadLocalMap作的put，get操做，因此存儲在當前線程中

 

ThreadLocal主要爲線程內部提供局部變量，這種變量在線程的生命週期內起做用。它並不能解決多線程訪問共享變量，只爲每一個線程建立一個單獨的變量副本。

 

每一個Thread維護一個ThreadLocalMap映射表，這個映射表的key是ThreadLocal實例自己，value是真正須要存儲的Object。ThreadLocalMap是使用ThreadLocal的弱引用做爲Key的，弱引用的對象在GC時會被回收

ThreadLocal中是有一個Map，但這個Map不是咱們平時使用的Map，而是ThreadLocalMap，ThreadLocalMap是ThreadLocal的一個內部類，不對外使用的。當使用ThreadLocal存值時，首先是獲取到當前線程對象，而後獲取到當前線程本地變量Map，最後將當前使用的ThreadLocal和傳入的值放到Map中，也就是說ThreadLocalMap中存的值是[ThreadLocal對象, 存放的值]，這樣作的好處是，每一個線程都對應一個本地變量的Map，因此一個線程能夠存在多個線程本地變量。

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);    //return t.threadLocals;
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this); 
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

 

應用場景經過爲每一個線程提供一個獨立的變量副本解決了變量併發訪問的衝突問題。通常來講，ThreadLocal比直接使用synchronized同步機制解決線程安全問題更簡單，更方便，且對併發性處理效果更好。例如：在併發環境下，服務器爲每一個用戶開一個線程建立一個ThreadLocal變量來存放用戶信息；對於數據庫的併發操做，咱們能夠用一個ThreadLocal變量來存放Connection；在spring中也常常出現，如Bean、事務管理、任務調度、AOP等。

 

ThreadLocal好的使用習慣，是每次使用完ThreadLocal，都調用它的remove()方法，清除數據。防止內存泄漏

 

Java中的ThreadLocal類容許咱們建立只能被同一個線程讀寫的變量。所以，若是一段代碼含有一個ThreadLocal變量的引用，即便兩個線程同時執行這段代碼，它們也沒法訪問到對方的ThreadLocal變量。

如何建立ThreadLocal變量

如下代碼展現瞭如何建立一個ThreadLocal變量：

1	private ThreadLocal myThreadLocal = new ThreadLocal();

咱們能夠看到，經過這段代碼實例化了一個ThreadLocal對象。咱們只須要實例化對象一次，而且也不須要知道它是被哪一個線程實例化。雖然全部的線程都能訪問到這個ThreadLocal實例，可是每一個線程卻只能訪問到本身經過調用ThreadLocal的set()方法設置的值。即便是兩個不一樣的線程在同一個ThreadLocal對象上設置了不一樣的值，他們仍然沒法訪問到對方的值。

如何訪問ThreadLocal變量

一旦建立了一個ThreadLocal變量，你能夠經過以下代碼設置某個須要保存的值：

1	myThreadLocal.set("A thread local value」);

能夠經過下面方法讀取保存在ThreadLocal變量中的值：

1	String threadLocalValue = (String) myThreadLocal.get();

get()方法返回一個Object對象，set()對象須要傳入一個Object類型的參數。

 

InheritableThreadLocal

InheritableThreadLocal類是ThreadLocal類的子類。ThreadLocal中每一個線程擁有它本身的值，與ThreadLocal不一樣的是，InheritableThreadLocal容許一個線程以及該線程建立的全部子線程均可以訪問它保存的值。

【注：全部子線程都會繼承父線程保存的ThreadLocal值】

 

深刻分析 ThreadLocal 內存泄漏問題

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永遠沒法回收，形成內存泄漏。

 

其實，ThreadLocalMap的設計中已經考慮到這種狀況，也加上了一些防禦措施：在ThreadLocal的get(),set(),remove()的時候都會清除線程ThreadLocalMap裏全部key爲null的value。

 

可是這些被動的預防措施並不能保證不會內存泄漏：

• 使用static的ThreadLocal，延長了ThreadLocal的生命週期，可能致使的內存泄漏。

• 分配使用了ThreadLocal又再也不調用get(),set(),remove()方法，那麼就會致使內存泄漏。

爲何使用弱引用

從表面上看內存泄漏的根源在於使用了弱引用。網上的文章大多着重分析ThreadLocal使用了弱引用會致使內存泄漏，可是另外一個問題也一樣值得思考：爲何使用弱引用而不是強引用？

咱們先來看看官方文檔的說法：

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.

爲了應對很是大和長時間的用途，哈希表使用弱引用的 key。

下面咱們分兩種狀況討論：

• key 使用強引用：引用的ThreadLocal的對象被回收了，可是ThreadLocalMap還持有ThreadLocal的強引用，若是沒有手動刪除，ThreadLocal不會被回收，致使Entry內存泄漏。

• key 使用弱引用：引用的ThreadLocal的對象被回收了，因爲ThreadLocalMap持有ThreadLocal的弱引用，即便沒有手動刪除，ThreadLocal也會被回收。value在下一次ThreadLocalMap調用set,get，remove的時候會被清除。

比較兩種狀況，咱們能夠發現：因爲ThreadLocalMap的生命週期跟Thread同樣長，若是都沒有手動刪除對應key，都會致使內存泄漏，可是使用弱引用能夠多一層保障：弱引用ThreadLocal不會內存泄漏，對應的value在下一次ThreadLocalMap調用set,get,remove的時候會被清除。

 

所以，ThreadLocal內存泄漏的根源是：因爲ThreadLocalMap的生命週期跟Thread同樣長，若是沒有手動刪除對應key就會致使內存泄漏，而不是由於弱引用。

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

 

另可參照：

http://blog.csdn.net/ghsau/article/details/15732053

http://ifeve.com/java-threadlocal%E7%9A%84%E4%BD%BF%E7%94%A8/