1. 背景

ThreadLocal原始碼解讀，網上面早已經氾濫了，大多比較淺，甚至有的連基本原理都說的很有問題,包括百度搜索出來的第一篇高訪問量博文，說ThreadLocal內部有個map，鍵為執行緒物件，太誤導人了。

ThreadLocal非常適合對Java多執行緒程式設計感興趣的程式設計師作為入門類閱讀，原因兩方面：

1. 加上註釋原始碼也不過七八百行。
2. 結構清晰，程式碼簡潔。

本文重點導讀ThreadLocal中的巢狀內部類ThreadLocalMap，對ThreadLocal本身API的介紹簡略帶過。
讀ThreadLocal原始碼，不讀ThreadLocalMap的實現，和沒看過沒多大差別

2. 兩個問題

先回答兩個問題：

1. 什麼是ThreadLocal？
   ThreadLocal類顧名思義可以理解為執行緒本地變數。也就是說如果定義了一個ThreadLocal，每個執行緒往這個ThreadLocal中讀寫是執行緒隔離，互相之間不會影響的。它提供了一種將可變資料通過每個執行緒有自己的獨立副本從而實現執行緒封閉的機制。

2. 它大致的實現思路是怎樣的？
   Thread類有一個型別為ThreadLocal.ThreadLocalMap的例項變數threadLocals，也就是說每個執行緒有一個自己的ThreadLocalMap。ThreadLocalMap有自己的獨立實現，可以簡單地將它的key視作ThreadLocal，value為程式碼中放入的值（實際上key並不是ThreadLocal本身，而是它的一個弱引用）。每個執行緒在往某個ThreadLocal裡塞值的時候，都會往自己的ThreadLocalMap裡存，讀也是以某個ThreadLocal作為引用，在自己的map裡找對應的key，從而實現了執行緒隔離。

3. ThreadLocal的API

ThreadLocal的API其實沒多少好介紹的，這些API介紹網上早已爛大街了。

4. ThreadLocalMap的原始碼實現

ThreadLocalMap的原始碼實現，才是我們讀ThreadLocal原始碼真正要領悟的。看看大師Doug Lea和Joshua Bloch的鬼斧神工之作。

ThreadLocalMap提供了一種為ThreadLocal定製的高效實現，並且自帶一種基於弱引用的垃圾清理機制。
下面從基本結構開始一點點解讀。

4.1 儲存結構

既然是個map（注意不要與java.util.map混為一談，這裡指的是概念上的map），當然得要有自己的key和value，上面回答的問題2中也已經提及，我們可以將其簡單視作key為ThreadLocal，value為實際放入的值。之所以說是簡單視作

static class Entry extends WeakReference<java.lang.ThreadLocal<?>> {
    // 往ThreadLocal裡實際塞入的值
    Object value;

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

Entry便是ThreadLocalMap裡定義的節點，它繼承了WeakReference類，定義了一個型別為Object的value，用於存放塞到ThreadLocal裡的值。

4.2 為什麼要弱引用

讀到這裡，如果不問不答為什麼是這樣的定義形式，為什麼要用弱引用，等於沒讀懂原始碼。
因為如果這裡使用普通的key-value形式來定義儲存結構，實質上就會造成節點的生命週期與執行緒強繫結，只要執行緒沒有銷燬，那麼節點在GC分析中一直處於可達狀態，沒辦法被回收，而程式本身也無法判斷是否可以清理節點。弱引用是Java中四檔引用的第三檔，比軟引用更加弱一些，如果一個物件沒有強引用鏈可達，那麼一般活不過下一次GC。當某個ThreadLocal已經沒有強引用可達，則隨著它被垃圾回收，在ThreadLocalMap裡對應的Entry的鍵值會失效，這為ThreadLocalMap本身的垃圾清理提供了便利。

4.3 類成員變數與相應方法

/**
 * 初始容量，必須為2的冪
 */
private static final int INITIAL_CAPACITY = 16;

/**
 * Entry表，大小必須為2的冪
 */
private Entry[] table;

/**
 * 表裡entry的個數
 */
private int size = 0;

/**
 * 重新分配表大小的閾值，預設為0
 */
private int threshold; 

可以看到，ThreadLocalMap維護了一個Entry表或者說Entry陣列，並且要求表的大小必須為2的冪，同時記錄表裡面entry的個數以及下一次需要擴容的閾值。
顯然這裡會產生一個問題，為什麼必須是2的冪？很好，但是目前還無法回答，帶著問題接著往下讀。

/**
 * 設定resize閾值以維持最壞2/3的裝載因子
 */
private void setThreshold(int len) {
    threshold = len * 2 / 3;
}

/**
 * 環形意義的下一個索引
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * 環形意義的上一個索引
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

ThreadLocal需要維持一個最壞2/3的負載因子，對於負載因子相信應該不會陌生，在HashMap中就有這個概念。
ThreadLocal有兩個方法用於得到上一個/下一個索引，注意這裡實際上是環形意義下的上一個與下一個。

由於ThreadLocalMap使用線性探測法來解決雜湊衝突，所以實際上Entry[]陣列在程式邏輯上是作為一個環形存在的。
關於開放定址、線性探測等內容，可以參考網上資料或者TAOCP（《計算機程式設計藝術》）第三卷的6.4章節。

至此，我們已經可以大致勾勒出ThreadLocalMap的內部儲存結構。下面是我繪製的示意圖。虛線表示弱引用，實線表示強引用。

ThreadLocalMap維護了Entry環形陣列，陣列中元素Entry的邏輯上的key為某個ThreadLocal物件（實際上是指向該ThreadLocal物件的弱引用），value為程式碼中該執行緒往該ThreadLoacl變數實際塞入的值。

4.4 建構函式

好的，接下來再來看看ThreadLocalMap的一個建構函式

/**
 * 構造一個包含firstKey和firstValue的map。
 * ThreadLocalMap是惰性構造的，所以只有當至少要往裡面放一個元素的時候才會構建它。
 */
ThreadLocalMap(java.lang.ThreadLocal<?> firstKey, Object firstValue) {
    // 初始化table陣列
    table = new Entry[INITIAL_CAPACITY];
    // 用firstKey的threadLocalHashCode與初始大小16取模得到雜湊值
    int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
    // 初始化該節點
    table[i] = new Entry(firstKey, firstValue);
    // 設定節點表大小為1
    size = 1;
    // 設定擴容閾值
    setThreshold(INITIAL_CAPACITY);
}

這個建構函式在set和get的時候都可能會被間接呼叫以初始化執行緒的ThreadLocalMap。

4.5 雜湊函式

重點看一下上面建構函式中的int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);這一行程式碼。

ThreadLocal類中有一個被final修飾的型別為int的threadLocalHashCode，它在該ThreadLocal被構造的時候就會生成，相當於一個ThreadLocal的ID，而它的值來源於

/*
 * 生成hash code間隙為這個魔數，可以讓生成出來的值或者說ThreadLocal的ID較為均勻地分佈在2的冪大小的陣列中。
 */
private static final int HASH_INCREMENT = 0x61c88647;

private static int nextHashCode() {
    return nextHashCode.getAndAdd(HASH_INCREMENT);
}

可以看出，它是在上一個被構造出的ThreadLocal的ID/threadLocalHashCode的基礎上加上一個魔數0x61c88647的。這個魔數的選取與斐波那契雜湊有關，0x61c88647對應的十進位制為1640531527。斐波那契雜湊的乘數可以用(long) ((1L << 31) * (Math.sqrt(5) - 1))可以得到2654435769，如果把這個值給轉為帶符號的int，則會得到-1640531527。換句話說
(1L << 32) - (long) ((1L << 31) * (Math.sqrt(5) - 1))得到的結果就是1640531527也就是0x61c88647。通過理論與實踐，當我們用0x61c88647作為魔數累加為每個ThreadLocal分配各自的ID也就是threadLocalHashCode再與2的冪取模，得到的結果分佈很均勻。
ThreadLocalMap使用的是線性探測法，均勻分佈的好處在於很快就能探測到下一個臨近的可用slot，從而保證效率。這就回答了上文丟擲的為什麼大小要為2的冪的問題。為了優化效率。

對於& (INITIAL_CAPACITY - 1)，相信有過演算法競賽經驗或是閱讀原始碼較多的程式設計師，一看就明白，對於2的冪作為模數取模，可以用&(2^n-1)來替代%2^n，位運算比取模效率高很多。至於為什麼，因為對2^n取模，只要不是低n位對結果的貢獻顯然都是0，會影響結果的只能是低n位。

可以說在ThreadLocalMap中，形如key.threadLocalHashCode & (table.length - 1)（其中key為一個ThreadLocal例項）這樣的程式碼片段實質上就是在求一個ThreadLocal例項的雜湊值，只是在原始碼實現中沒有將其抽為一個公用函式。

4.6 getEntry方法

這個方法會被ThreadLocal的get方法直接呼叫，用於獲取map中某個ThreadLocal存放的值。

private Entry getEntry(ThreadLocal<?> key) {
    // 根據key這個ThreadLocal的ID來獲取索引，也即雜湊值
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    // 對應的entry存在且未失效且弱引用指向的ThreadLocal就是key，則命中返回
    if (e != null && e.get() == key) {
        return e;
    } else {
        // 因為用的是線性探測，所以往後找還是有可能能夠找到目標Entry的。
        return getEntryAfterMiss(key, i, e);
    }
}

/*
 * 呼叫getEntry未直接命中的時候呼叫此方法
 */
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;
   
    
    // 基於線性探測法不斷向後探測直到遇到空entry。
    while (e != null) {
        ThreadLocal<?> k = e.get();
        // 找到目標
        if (k == key) {
            return e;
        }
        if (k == null) {
            // 該entry對應的ThreadLocal已經被回收，呼叫expungeStaleEntry來清理無效的entry
            expungeStaleEntry(i);
        } else {
            // 環形意義下往後面走
            i = nextIndex(i, len);
        }
        e = tab[i];
    }
    return null;
}

/**
 * 這個函式是ThreadLocal中核心清理函式，它做的事情很簡單：
 * 就是從staleSlot開始遍歷，將無效（弱引用指向物件被回收）清理，即對應entry中的value置為null，將指向這個entry的table[i]置為null，直到掃到空entry。
 * 另外，在過程中還會對非空的entry作rehash。
 * 可以說這個函式的作用就是從staleSlot開始清理連續段中的slot（斷開強引用，rehash slot等）
 */
private int expungeStaleEntry(int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;

    // 因為entry對應的ThreadLocal已經被回收，value設為null，顯式斷開強引用
    tab[staleSlot].value = null;
    // 顯式設定該entry為null，以便垃圾回收
    tab[staleSlot] = null;
    size--;

    Entry e;
    int i;
    for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();
        // 清理對應ThreadLocal已經被回收的entry
        if (k == null) {
            e.value = null;
            tab[i] = null;
            size--;
        } else {
            /*
             * 對於還沒有被回收的情況，需要做一次rehash。
             * 
             * 如果對應的ThreadLocal的ID對len取模出來的索引h不為當前位置i，
             * 則從h向後線性探測到第一個空的slot，把當前的entry給挪過去。
             */
            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.
                 *
                 * 這段話提及了Knuth高德納的著作TAOCP（《計算機程式設計藝術》）的6.4章節（雜湊）
                 * 中的R演算法。R演算法描述瞭如何從使用線性探測的散列表中刪除一個元素。
                 * R演算法維護了一個上次刪除元素的index，當在非空連續段中掃到某個entry的雜湊值取模後的索引
                 * 還沒有遍歷到時，會將該entry挪到index那個位置，並更新當前位置為新的index，
                 * 繼續向後掃描直到遇到空的entry。
                 *
                 * ThreadLocalMap因為使用了弱引用，所以其實每個slot的狀態有三種也即
                 * 有效（value未回收），無效（value已回收），空（entry==null）。
                 * 正是因為ThreadLocalMap的entry有三種狀態，所以不能完全套高德納原書的R演算法。
                 *
                 * 因為expungeStaleEntry函式在掃描過程中還會對無效slot清理將之轉為空slot，
                 * 如果直接套用R演算法，可能會出現具有相同雜湊值的entry之間斷開（中間有空entry）。
                 */
                while (tab[h] != null) {
                    h = nextIndex(h, len);
                }
                tab[h] = e;
            }
        }
    }
    // 返回staleSlot之後第一個空的slot索引
    return i;
}

我們來回顧一下從ThreadLocal讀一個值可能遇到的情況：
根據入參threadLocal的threadLocalHashCode對錶容量取模得到index

• 如果index對應的slot就是要讀的threadLocal，則直接返回結果
• 呼叫getEntryAfterMiss線性探測，過程中每碰到無效slot，呼叫expungeStaleEntry進行段清理；如果找到了key，則返回結果entry
• 沒有找到key，返回null

4.7 set方法

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();
        // 找到對應的entry
        if (k == key) {
            e.value = value;
            return;
        }
        // 替換失效的entry
        if (k == null) {
            replaceStaleEntry(key, value, i);
            return;
        }
    }

    tab[i] = new Entry(key, value);
    int sz = ++size;
    if (!cleanSomeSlots(i, sz) && sz >= threshold) {
        rehash();
    }
}

private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                               int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;
    Entry e;

    // 向前掃描，查詢最前的一個無效slot
    int slotToExpunge = staleSlot;
    for (int i = prevIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = prevIndex(i, len)) {
        if (e.get() == null) {
            slotToExpunge = i;
        }
    }

    // 向後遍歷table
    for (int i = nextIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();

        // 找到了key，將其與無效的slot交換
        if (k == key) {
            // 更新對應slot的value值
            e.value = value;

            tab[i] = tab[staleSlot];
            tab[staleSlot] = e;

            /*
             * 如果在整個掃描過程中（包括函式一開始的向前掃描與i之前的向後掃描）
             * 找到了之前的無效slot則以那個位置作為清理的起點，
             * 否則則以當前的i作為清理起點
             */
            if (slotToExpunge == staleSlot) {
                slotToExpunge = i;
            }
            // 從slotToExpunge開始做一次連續段的清理，再做一次啟發式清理
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
            return;
        }

        // 如果當前的slot已經無效，並且向前掃描過程中沒有無效slot，則更新slotToExpunge為當前位置
        if (k == null && slotToExpunge == staleSlot) {
            slotToExpunge = i;
        }
    }

    // 如果key在table中不存在，則在原地放一個即可
    tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

    // 在探測過程中如果發現任何無效slot，則做一次清理（連續段清理+啟發式清理）
    if (slotToExpunge != staleSlot) {
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
    }
}

/**
 * 啟發式地清理slot,
 * i對應entry是非無效（指向的ThreadLocal沒被回收，或者entry本身為空）
 * n是用於控制控制掃描次數的
 * 正常情況下如果log n次掃描沒有發現無效slot，函式就結束了
 * 但是如果發現了無效的slot，將n置為table的長度len，做一次連續段的清理
 * 再從下一個空的slot開始繼續掃描
 * 
 * 這個函式有兩處地方會被呼叫，一處是插入的時候可能會被呼叫，另外個是在替換無效slot的時候可能會被呼叫，
 * 區別是前者傳入的n為元素個數，後者為table的容量
 */
private boolean cleanSomeSlots(int i, int n) {
    boolean removed = false;
    Entry[] tab = table;
    int len = tab.length;
    do {
        // i在任何情況下自己都不會是一個無效slot，所以從下一個開始判斷
        i = nextIndex(i, len);
        Entry e = tab[i];
        if (e != null && e.get() == null) {
            // 擴大掃描控制因子
            n = len;
            removed = true;
            // 清理一個連續段
            i = expungeStaleEntry(i);
        }
    } while ((n >>>= 1) != 0);
    return removed;
}


private void rehash() {
    // 做一次全量清理
    expungeStaleEntries();

    /*
     * 因為做了一次清理，所以size很可能會變小。
     * ThreadLocalMap這裡的實現是調低閾值來判斷是否需要擴容，
     * threshold預設為len*2/3，所以這裡的threshold - threshold / 4相當於len/2
     */
    if (size >= threshold - threshold / 4) {
        resize();
    }
}

/*
 * 做一次全量清理
 */
private void expungeStaleEntries() {
    Entry[] tab = table;
    int len = tab.length;
    for (int j = 0; j < len; j++) {
        Entry e = tab[j];
        if (e != null && e.get() == null) {
            /*
             * 個人覺得這裡可以取返回值，如果大於j的話取了用，這樣也是可行的。
             * 因為expungeStaleEntry執行過程中是把連續段內所有無效slot都清理了一遍了。
             */
            expungeStaleEntry(j);
        }
    }
}

/**
 * 擴容，因為需要保證table的容量len為2的冪，所以擴容即擴大2倍
 */
private void resize() {
    Entry[] oldTab = table;
    int oldLen = oldTab.length;
    int newLen = oldLen * 2;
    Entry[] newTab = new Entry[newLen];
    int count = 0;

    for (int j = 0; j < oldLen; ++j) {
        Entry e = oldTab[j];
        if (e != null) {
            ThreadLocal<?> k = e.get();
            if (k == null) {
                e.value = null; 
            } else {
                // 線性探測來存放Entry
                int h = k.threadLocalHashCode & (newLen - 1);
                while (newTab[h] != null) {
                    h = nextIndex(h, newLen);
                }
                newTab[h] = e;
                count++;
            }
        }
    }

    setThreshold(newLen);
    size = count;
    table = newTab;
}

我們來回顧一下ThreadLocal的set方法可能會有的情況

• 探測過程中slot都不無效，並且順利找到key所在的slot，直接替換即可
• 探測過程中發現有無效slot，呼叫replaceStaleEntry，效果是最終一定會把key和value放在這個slot，並且會盡可能清理無效slot
  • 在replaceStaleEntry過程中，如果找到了key，則做一個swap把它放到那個無效slot中，value置為新值
  • 在replaceStaleEntry過程中，沒有找到key，直接在無效slot原地放entry
• 探測沒有發現key，則在連續段末尾的後一個空位置放上entry，這也是線性探測法的一部分。放完後，做一次啟發式清理，如果沒清理出去key，並且當前table大小已經超過閾值了，則做一次rehash，rehash函式會呼叫一次全量清理slot方法也即expungeStaleEntries，如果完了之後table大小超過了threshold - threshold / 4，則進行擴容2倍

4.8 remove方法

/**
 * 從map中刪除ThreadLocal
 */
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) {
            // 顯式斷開弱引用
            e.clear();
            // 進行段清理
            expungeStaleEntry(i);
            return;
        }
    }
}

remove方法相對於getEntry和set方法比較簡單，直接在table中找key，如果找到了，把弱引用斷了做一次段清理。

5. ThreadLocal與記憶體洩漏

關於ThreadLocal是否會引起記憶體洩漏也是一個比較有爭議性的問題，其實就是要看對記憶體洩漏的準確定義是什麼。
認為ThreadLocal會引起記憶體洩漏的說法是因為如果一個ThreadLocal物件被回收了，我們往裡面放的value對於【當前執行緒->當前執行緒的threadLocals(ThreadLocal.ThreadLocalMap物件）->Entry陣列->某個entry.value】這樣一條強引用鏈是可達的，因此value不會被回收。
認為ThreadLocal不會引起記憶體洩漏的說法是因為ThreadLocal.ThreadLocalMap原始碼實現中自帶一套自我清理的機制。

之所以有關於記憶體洩露的討論是因為在有執行緒複用如執行緒池的場景中，一個執行緒的壽命很長，大物件長期不被回收影響系統執行效率與安全。如果執行緒不會複用，用完即銷燬了也不會有ThreadLocal引發記憶體洩露的問題。《Effective Java》一書中的第6條對這種記憶體洩露稱為unintentional object retention(無意識的物件保留）。

當我們仔細讀過ThreadLocalMap的原始碼，我們可以推斷，如果在使用的ThreadLocal的過程中，顯式地進行remove是個很好的編碼習慣，這樣是不會引起記憶體洩漏。
那麼如果沒有顯式地進行remove呢？只能說如果對應執行緒之後呼叫ThreadLocal的get和set方法都有很高的概率會順便清理掉無效物件，斷開value強引用，從而大物件被收集器回收。

但無論如何，我們應該考慮到何時呼叫ThreadLocal的remove方法。一個比較熟悉的場景就是對於一個請求一個執行緒的server如tomcat，在程式碼中對web api作一個切面，存放一些如使用者名稱等使用者資訊，在連線點方法結束後，再顯式呼叫remove。

6. InheritableThreadLocal原理

對於InheritableThreadLocal，本文不作過多介紹，只是簡單略過。
ThreadLocal本身是執行緒隔離的，InheritableThreadLocal提供了一種父子執行緒之間的資料共享機制。

它的具體實現是在Thread類中除了threadLocals外還有一個inheritableThreadLocals物件。

線上程物件初始化的時候，會呼叫ThreadLocal的createInheritedMap從父執行緒的inheritableThreadLocals中把有效的entry都拷過來

可以看一下其中的具體實現

private ThreadLocalMap(ThreadLocalMap parentMap) {
    Entry[] parentTable = parentMap.table;
    int len = parentTable.length;
    setThreshold(len);
    table = new Entry[len];

    for (int j = 0; j < len; j++) {
        Entry e = parentTable[j];
        if (e != null) {
            @SuppressWarnings("unchecked")
            ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
            if (key != null) {
                // 這裡的childValue方法在InheritableThreadLocal中預設實現為返回本身值，可以被重寫
                Object value = key.childValue(e.value);
                Entry c = new Entry(key, value);
                int h = key.threadLocalHashCode & (len - 1);
                while (table[h] != null)
                    h = nextIndex(h, len);
                table[h] = c;
                size++;
            }
        }
    }
}

還是比較簡單的，做的事情就是以父執行緒的inheritableThreadLocalMap為資料來源，過濾出有效的entry，初始化到自己的inheritableThreadLocalMap中。其中childValue可以被重寫。

需要注意的地方是InheritableThreadLocal只是在子執行緒建立的時候會去拷一份父執行緒的inheritableThreadLocals。如果父執行緒是在子執行緒建立後再set某個InheritableThreadLocal物件的值，對子執行緒是不可見的。

7. 總結

本博文重點介紹了ThreadLocal中ThreadLocalMap的大致實現原理以及ThreadLocal記憶體洩露的問題以及簡略介紹InheritableThreadLocal。作為Josh Bloch和Doug Lea兩位大師之作，ThreadLocal本身實現的演算法與技巧還是很優雅的。在開發過程中，ThreadLocal用到恰到好處的話，可以消除一些程式碼的重複。但也要注意過度使用ThreadLocal很容易加大類之間的耦合度與依賴關係（開發過程可能會不得不過度考慮某個ThreadLocal在呼叫時是否已有值，存放的是哪個類放的什麼值）