ThreadLocal是什麼

首先，它是一個數據結構，有點像HashMap，可以保存"key : value"鍵值對，但是一個ThreadLocal只能保存一個，並且各個線程的數據互不干擾。

ThreadLocal用於保存某個線程共享變量：對於同一個static ThreadLocal，不同線程只能從中get，set，remove自己的變量，而不會影響其他線程的變量, 在高併發場景下，可以實現無狀態的調用，特別適用於各個線程依賴不同的變量值完成操作的場景。

先看一個例子來體會什麼叫不同線程從中get,set自己的變量

public class ThreadLocalTest {
  
    public static class MyRunnable implements Runnable {
  
        private ThreadLocal<Integer> threadLocal = new ThreadLocal<Integer>();
  
        public MyRunnable(){
            threadLocal.set((int) (Math.random() * 100D));
            System.out.println(Thread.currentThread().getName() + ":" + threadLocal.get());
        }
  
        @Override
        public void run() {
            System.out.println(Thread.currentThread().getName() + ":" + threadLocal.get());
        }
    }
  
  
    public static void main(String[] args) {
        Thread t = new Thread(new MyRunnable(), "A");
        t.start();
    }
}

把ThreadLocal賦值的地方放在了MyRunnable的構造函數中，然後在run方法中讀取該值，看下結果：

main:1
A:null

思考一下：
爲什麼會這樣？ MyRunnable的構造函數是由main主線程調用的，所以TheadLocal的set方法，實際上是在main主線程的環境中完成的，因此也只能在main主線程中get到，而run方法運行的上下文是子線程本身，由於run方法中並沒有使用set方法賦值，因此get到的是默認空值null.

實現原理

如果給你設計，你會怎麼設計？相信大部分人會有這樣的想法：

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

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

我們先看看JDK8的ThreadLocal的get方法的源碼:

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

從代碼上看，主要思路如下：

取當前線程
取得ThreadLocalMap類（先不管這個的實現，從命名上看，理解成一個Map<K,V>容器即可）
如果Map容器不爲空，則根據ThreadLocal自身的HashCode(見後面的繼續分析)取得對應的Entry(即Map裏的k-v元素對)
如果entry不爲空，則返回值
如果Map容器爲空，則設置初始值

可以發現，每個線程中都有一個ThreadLocalMap數據結構，當執行set方法時，其值是保存在當前線程的threadLocals變量中，當執行set方法中，是從當前線程的threadLocals變量獲取。

所以在線程1中set的值，對線程2來說是摸不到的，而且在線程2中重新set的話，也不會影響到線程1中的值，保證了線程之間不會相互干擾。

那每個線程中的ThreadLoalMap究竟是什麼？

ThreadLoalMap

從名字上看，可以猜到它也是一個類似HashMap的數據結構，但是在ThreadLocal中，並沒實現Map接口。

在ThreadLoalMap中，也是初始化一個大小16的Entry數組，Entry對象用來保存每一個key-value鍵值對，只不過這裏的key永遠都是ThreadLocal對象，是不是很神奇，通過ThreadLocal對象的set方法，結果把ThreadLocal對象自己當做key，放進了ThreadLoalMap中。

這裏需要注意的是，ThreadLoalMap的Entry是繼承WeakReference，和HashMap很大的區別是，Entry中沒有next字段，所以就不存在鏈表的情況了。

hash衝突

沒有鏈表結構，那發生hash衝突了怎麼辦？

先看看ThreadLoalMap中插入一個key-value的實現( ThreadLoalMap 初始容量16，負載因子2/3 )

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

ThreadLocalMap解決Hash衝突的方式就是簡單的步長加1或減1，尋找下一個相鄰的位置。

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

顯然ThreadLocalMap採用線性探測的方式解決Hash衝突的效率很低，如果有大量不同的ThreadLocal對象放入map中時發送衝突，或者發生二次衝突，則效率很低。

所以這裏引出的良好建議是：每個線程只存一個變量，這樣的話所有的線程存放到map中的Key都是相同的ThreadLocal，如果一個線程要保存多個變量，就需要創建多個ThreadLocal，多個ThreadLocal放入Map中時會極大的增加Hash衝突的可能。

ThreadLocalMap的問題

每個ThreadLocal對象都有一個hash值threadLocalHashCode，每初始化一個ThreadLocal對象，hash值就增加一個固定的大小0x61c88647。

在插入過程中，根據ThreadLocal對象的hash值，定位到table中的位置i，過程如下：
1、如果當前位置是空的，那麼正好，就初始化一個Entry對象放在位置i上；
2、不巧，位置i已經有Entry對象了，如果這個Entry對象的key正好是即將設置的key，那麼重新設置Entry中的value；
3、很不巧，位置i的Entry對象，和即將設置的key沒關係，那麼只能找下一個空位置；

這樣的話，在get的時候，也會根據ThreadLocal對象的hash值，定位到table中的位置，然後判斷該位置Entry對象中的key是否和get的key一致，如果不一致，就判斷下一個位置

可以發現，set和get如果衝突嚴重的話，效率很低，因爲ThreadLoalMap是Thread的一個屬性，所以即使在自己的代碼中控制了設置的元素個數，但還是不能控制其它代碼的行爲。

ThreadLocal的getMap及ThreadLocalMap的getEntry方法

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

可以發現getMap其實取的是Thread實例t上的一個屬性，繼續看Thread的代碼：

/* ThreadLocal values pertaining to this thread. This map is maintained

 * by the ThreadLocal class. */

ThreadLocal.ThreadLocalMap threadLocals = null;
  

/*

 * InheritableThreadLocal values pertaining to this thread. This map is

 * maintained by the InheritableThreadLocal class.

 */

ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

說明每個Thread內部都維護着二個ThreadLocalMap，一個應對threadLocals(即：一個Thread內部可以有多個ThreadLocal實例)，另一個對應着 inheritableThreadLocals，再看ThreadLocal.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);
        }

從這裏看，ThreadLocalMap的key是基於ThreadLocal的Hashcode與內部table的長度-1做位運算的整數值，只要有個印象，threadLocalMap的key跟ThreadLocal實例的hashcode有關即可。

最後看看ThreadLocal的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;
    }

先根據當前線程實例t，找到內部維護的ThreadLocalMap容器，如果容器爲空，則創建Map實例，否則直接把值放進去（Key跟ThreadLocal實例本身的hashCode相關）。

remove()方法

/**
 * Removes the current thread's value for this thread-local
 * variable.  If this thread-local variable is subsequently
 * {@linkplain #get read} by the current thread, its value will be
 * reinitialized by invoking its {@link #initialValue} method,
 * unless its value is {@linkplain #set set} by the current thread
 * in the interim.  This may result in multiple invocations of the
 * <tt>initialValue</tt> method in the current thread.
 *
 * @since 1.5
 */
public void remove() {
 ThreadLocalMap m = getMap(Thread.currentThread());
 if (m != null)
     m.remove(this);
}

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

remove方法比較簡單，不做贅述。

根據以上分析，對於ThreadLocal的內部實現，其主要思路總結如下：

每個Thread實例內部，有兩個ThreadLocalMap的K-V容器實例（分別對應threadLocals及inheritableThreadLocals）, 容器的元素數量，即爲Thread實例裏的ThreadLocal實例個數
ThreadLocalMap裏的每個Entry的Key與ThreadLocal實例的HashCode相關（這樣，多個ThreadLocal實例就不會搞混）
每個ThreadLocal實例使用set賦值時，實際上是在ThreadLocalMap容器裏，添加(或更新)一條Entry信息
每個ThreadLocal實例使用get取值時，從ThreadLocalMap里根據key取出value 。

所以，可以總結一下ThreadLocal的設計思路：
每個Thread維護一個ThreadLocalMap映射表，這個映射表的key是ThreadLocal實例本身，value是真正需要存儲的Object。
這個方案剛好與我們開始說的簡單的設計方案相反。查閱了一下資料，這樣設計的主要有以下幾點優勢：

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

內存泄露

ThreadLocal可能導致內存泄漏，爲什麼？
先看看Entry的實現：

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

通過之前的分析已經知道，當使用ThreadLocal保存一個value時，會在ThreadLocalMap中的數組插入一個Entry對象，按理說key-value都應該以強引用保存在Entry對象中，但在ThreadLocalMap的實現中，key被保存到了WeakReference對象中。

根據上面Entry方法的源碼，我們知道ThreadLocalMap是使用ThreadLocal的弱引用作爲Key的。下圖是本文介紹到的一些對象之間的引用關係圖，實線表示強引用，虛線表示弱引用：

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

如何避免內存泄露

既然已經發現有內存泄露的隱患，自然有應對的策略，在調用ThreadLocal的get()、set()可能會清除ThreadLocalMap中key爲null的Entry對象，這樣對應的value就沒有GC Roots可達了，下次GC的時候就可以被回收，但是光這樣還是不夠的，上面的設計思路依賴一個前提條件：要調用ThreadLocalMap的genEntry函數或者set函數。這當然是不可能任何情況都成立的當然如果調用remove方法，肯定會刪除對應的Entry對象。

如果使用ThreadLocal的set方法之後，沒有顯示的調用remove方法，就有可能發生內存泄露，所以養成良好的編程習慣十分重要，使用完ThreadLocal之後，記得調用remove方法。

ThreadLocal<String> localName = new ThreadLocal();
try {
    localName.set("aaa");
    // 其它業務邏輯
} finally {
    localName.remove();
}

JDK建議將ThreadLocal變量修飾符定義成private static，這樣的話ThreadLocal的生命週期就更長，由於一直存在ThreadLocal的強引用，所以ThreadLocal也就不會被回收，也就能保證任何時候都能根據ThreadLocal的弱引用訪問到Entry的value值，然後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就會導致內存泄漏，而不是因爲弱引用。

應用場景

最常見的ThreadLocal使用場景爲用來解決 數據庫連接、Session管理等。

還記得Hibernate的session獲取場景嗎？

private static final ThreadLocal<Session> threadLocal = new ThreadLocal<Session>();

//獲取Session
public static Session getCurrentSession(){
    Session session =  threadLocal.get();
    //判斷Session是否爲空，如果爲空，將創建一個session，並設置到本地線程變量中
    try {
        if(session ==null&&!session.isOpen()){
            if(sessionFactory==null){
                rbuildSessionFactory();// 創建Hibernate的SessionFactory
            }else{
                session = sessionFactory.openSession();
            }
        }
        threadLocal.set(session);
    } catch (Exception e) {
        // TODO: handle exception
    }

    return session;
}

爲什麼？每個線程訪問數據庫都應當是一個獨立的Session會話，如果多個線程共享同一個Session會話，有可能其他線程關閉連接了，當前線程再執行提交時就會出現會話已關閉的異常，導致系統異常。此方式能避免線程爭搶Session，提高併發下的安全性。

使用ThreadLocal的典型場景正如上面的數據庫連接管理，線程會話管理等場景，只適用於獨立變量副本的情況，如果變量爲全局共享的，則不適用在高併發下使用。