---

1. 為什么需要ThreadLocal

我們從Java操作實現MySQL事務的角度去看

不難發現,如果通過上面的步驟,那么開啟事務的連接和執行操作的連接不是同一個,勢必會導致事務的失效

那么怎么解決上面的問題呢?

一種簡單直接的方法就是,執行操作的時候將開啟事務的連接作為方法參數傳遞給實際操作的方法

但是我們平常在使用Mybatis的時候從來沒有這樣傳遞過參數

也就是說spring自動幫我們解決了這個問題

那么它是怎么做到的?? Spring 是使用一個 ThreadLocal 來實現“綁定連接到線程”的。

ThreadLocal:

此類提供線程局部變量。這些變量與普通對應變量的不同之處在于， 訪問一 個變量的每個線程（通過其 get 或 set 方法）都有自己獨立初始化的變量副本。 ThreadLocal 實例通常是希望將狀態與線程（例如， 用戶 ID 或事務 ID）相關聯 的類中的私有靜態字段。也就是說 ThreadLocal 為每個線程都提供了變量的副本，使得每個線程在某 一時間訪問到的并非同一個對象，這樣就隔離了多個線程對數據的數據共享。

ThreadLocal 的一大應用場景就是跨方法進行參數傳遞，比如 Web 容器中， 每個完整的請求周期會由一個線程來處理。 結合 ThreadLocal 再使用 Spring 里的 IOC 和 AOP，就可以很好的解決我們上面的事務的問題。只要將一個數據庫連接 放入 ThreadLocal 中， 當前線程執行時只要有使用數據庫連接的地方就從ThreadLocal 獲得就行了。

ThreadLocal 類接口很簡單，只有 4 個方法，我們先來了解一下：

? void set(Object value)

設置當前線程的線程局部變量的值。

? public Object get()

該方法返回當前線程所對應的線程局部變量。

? public void remove()

將當前線程局部變量的值刪除， 目的是為了減少內存的占用， 該方法是 JDK 5.0 新增的方法。

? protected Object inialValue()

返回該線程局部變量的初始值，該方法是一個 protected 的方法， 顯然是為 了讓子類覆蓋而設計的。這個方法是一個延遲調用方法， 在線程第 1 次調用 get() 或 set(Object)時才執行，并且僅執行 1次。ThreadLocal 中的缺省實現直接返回一 個 null。

2. ThreadLocal的實現解析

1.1 實現分析

怎么實現 ThreadLocal，既然說讓每個線程都擁有自己變量的副本，最容易 的方式就是用一個Map 將線程的副本存放起來， Map 里 key 就是每個線程的唯 一性標識，比如線程 ID ，value 就是副本值， 實現起來也很簡單：

public class MyThreadLocal<T> {private Map<Thread, T> threadMap = new HashMap<>();public synchronized T get() {return threadMap.get(Thread.currentThread());}public synchronized void set(T t) {threadMap.put(Thread.currentThread(), t);}
}

考慮到并發安全性， 對數據的存取用 synchronize 關鍵字加鎖， 但是 DougLee 在《并發編程實戰》中為我們做過性能測試

可以看到 ThreadLocal 的性能遠超類似 synchronize 的鎖實現 ReentrantLock， 比AtomicInteger 也要快很多，即使我們把 Map 的實現更換為Java 中專為并發設計的 ConcurrentHashMap也不太可能達到這么高的性能。

怎么樣設計可以讓 ThreadLocal 達到這么高的性能呢？最好的辦法則是讓變 量副本跟隨著線程本身， 而不是將變量副本放在一個地方保存， 這樣就可以在存 取時避開線程之間的競爭。

同時，因為每個線程所擁有的變量的副本數是不定的， 有些線程可能有一個， 有些線程可能有 2個甚至更多， 則線程內部存放變量副本需要一個容器， 而且容器要支持快速存取， 所以在每個線程內部都可以持有一個 Map 來支持多個變量副本，這個 Map 被稱為 ThreadLocalMap

1.2 具體實現

上面說到的ThreadLocalMap,實際上就實現了讓變量副本跟隨著線程

可以看到,這個ThreadLocalMap實際上就是一個Map,以ThreadLocal作為鍵,用戶數據作為值

雖然這個類定義在ThreadLocal類中,但是它是聲明在Thread中的

這樣就能讓變量副本跟隨者線程

我們再來看ThreadLocal的get方法

面先取到當前線程，然后調用 getMap 方法獲取對應的 ThreadLocalMap,再從ThreadLocalMap中獲取當前ThreadLocal對應的值

從而實現一個線程能保存多份變量副本

1.3 ThreadLocalMap中Hash沖突的解決

1.3.1 Hash沖突解決的幾種方法

1.3.1.1 開放定值法

基本思想是，出現沖突后按照一定算法查找一個空位置存放，根據算法的不 同又可以分為線性探測再散列、二次探測再散列、偽隨機探測再散列。

• 線性探測再散列,即依次向后查找
• 二次探測再散列， 即依次向前后查找， 增 量為 1 、2 、3 的二次方
• 偽隨機，顧名思義就是隨機產生一個增量位移

1.3.1.2 鏈地址法

這種方法的基本思想是將所有哈希地址為 i 的元素構成一個稱為同義詞鏈的單鏈表， 并將單鏈表的頭指針存在哈希表的第 i 個單元中， 因而查找、插入和刪 除主要在同義詞鏈中進行。鏈地址法適用于經常進行插入和刪除的情況。 Java里的 HashMap 用的就是鏈地址法，為了避免 hash 洪水攻擊，1.8 版本開始還引 入了紅黑樹

1.3.1.3再哈希法：

這種方法是同時構造多個不同的哈希函數： Hi=RH1（key） i=1 ，2 ，… ，k 當哈希地址 Hi=RH1（key）發生沖突時，再計算 Hi=RH2（key）……，直到沖突 不再產生。這種方法不易產生聚集，但增加了計算時間

1.3.1.4 建立公共溢出區

這種方法的基本思想是： 將哈希表分為基本表和溢出表兩部分， 凡是和基本 表發生沖突的元

素， 一律填入溢出表。

1.3.2 ThreadLocal解決Hash沖突的方法

ThreadLocal 里用的是線性探測再散列

3. ThreadLocal引發的內存泄漏分析

3.1 強引用、軟應用、弱引用和虛引用

• 強引用就是指在程序代碼之中普遍存在的， 類似“Object obj=new Object（）” 這類的引用， 只要強引用還存在， 垃圾收集器永遠不會回收掉被引用的對象實例。
• 軟引用是用來描述一些還有用但并非必需的對象。對于軟引用關聯著的對象， 在系統將要發生內存溢出異常之前， 將會把這些對象實例列進回收范圍之中進行 第二次回收。如果這次回收還沒有足夠的內存， 才會拋出內存溢出異常。在 JDK 1.2 之后，提供了 SoReference 類來實現軟引用。
• 弱引用也是用來描述非必需對象的， 但是它的強度比軟引用更弱一些，被弱引用關聯的對象實例只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象實例。在 JDK 1.2 之 后，提供了WeakReference 類來實現弱引用。
• 虛引用也稱為幽靈引用或者幻影引用， 它是最弱的一種引用關系。一個對象實例是否有虛引用的存在， 完全不會對其生存時間構成影響， 也無法通過虛引用來取得一個對象實例。為一個對象設置虛引用關聯的唯一目的就是能在這個對象實例被收集器回收時收到一個系統通知。在 JDK 1.2 之后，提供了PhantomReference 類來實現虛引用。

3.2 內存泄露的現象

public class ThreadLocalMemoryLeakTest {// 創建固定大小的線程池，核心線程和最大線程數都是5final static ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new LinkedBlockingDeque<>());// 定義一個占用5M內存的本地變量類static class LocalVariable {// 大約5M的字節數組byte[] bytes = new byte[1024 * 1024 * 5];}// ThreadLocal變量，用于存儲LocalVariablestatic ThreadLocal<LocalVariable> threadLocal = new ThreadLocal<>();public static void main(String[] args) throws InterruptedException {testCase1();}

3.2.1 第一組測試

僅從線程池獲取線程，不做任何操作

/*** 測試場景1：僅從線程池獲取線程，不做任何操作*/public static void testCase1() throws InterruptedException {System.out.println("執行測試場景1：僅使用線程池，不做任何操作");while (true) {poolExecutor.execute(() -> {System.out.println("線程" + Thread.currentThread().getId() + "執行完畢");try {// 短暫休眠，模擬任務執行時間Thread.sleep(100);} catch (InterruptedException e) {e.printStackTrace();}});// 控制任務提交速度Thread.sleep(50);}}

通過visualvm工具可以看到內存占用很小

3.2.2 第二組測試

創建LocalVariable但不使用ThreadLocal

/*** 測試場景2：創建LocalVariable但不使用ThreadLocal*/
public static void testCase2() throws InterruptedException {
System.out.println("執行測試場景2：創建LocalVariable但不使用ThreadLocal");while (true) {poolExecutor.execute(() -> {// 創建本地變量，但不存儲到ThreadLocalLocalVariable var = new LocalVariable();System.out.println("線程" + Thread.currentThread().getId() + "創建了LocalVariable");try {Thread.sleep(100);} catch (InterruptedException e) {e.printStackTrace();}// 方法結束后，var會被GC回收});Thread.sleep(50);
}
}

在GC的作用下,無用的對象會被回收,內存占用會下降到正常水平

3.2.3 第三組測試

使用ThreadLocal存儲LocalVariable但不清理

 /*** 測試場景3：使用ThreadLocal存儲LocalVariable但不清理*/public static void testCase3() throws InterruptedException {System.out.println("執行測試場景3：使用ThreadLocal存儲但不清理");while (true) {poolExecutor.execute(() -> {// 存儲變量到ThreadLocal，但不調用remove()threadLocal.set(new LocalVariable());System.out.println("線程" + Thread.currentThread().getId() + "向ThreadLocal存儲了變量");try {Thread.sleep(100);} catch (InterruptedException e) {e.printStackTrace();}// 不清理ThreadLocal，可能導致內存泄露});Thread.sleep(50);}}

可以看到,與2不同的是,盡管有GC的作用,但是占用的內存還是超出預料范圍

3.2.4 第四組測試

使用ThreadLocal存儲并正確清理

 /*** 測試場景4：使用ThreadLocal存儲并正確清理*/public static void testCase4() throws InterruptedException {System.out.println("執行測試場景4：使用ThreadLocal存儲并清理");while (true) {poolExecutor.execute(() -> {try {// 存儲變量到ThreadLocalthreadLocal.set(new LocalVariable());System.out.println("線程" + Thread.currentThread().getId() + "向ThreadLocal存儲了變量并清理");Thread.sleep(100);} catch (InterruptedException e) {e.printStackTrace();} finally {// 手動清理ThreadLocal，避免內存泄露threadLocal.remove();}});Thread.sleep(50);}}

可以看到,在GC的作用下,現象與第二組測試基本一致

3.3 內存泄露的分析

根據我們前面對 ThreadLocal 的分析，我們可以知道每個 Thread 維護一個 ThreadLocalMap，這個映射表的 key 是 ThreadLocal 實例本身， value 是真正需 要存儲的 Object，也就是說 ThreadLocal 本身并不存儲值， 它只是作為一個 key 來讓線程從 ThreadLocalMap 獲取 value。

仔細觀察ThreadLocalMap，這個 map 是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的對象在 GC 時會被回收

那么此時的引用鏈路關系就是:

圖中的虛線表示弱引用

這 樣 ， 當 把 threadlocal 變 量 置 為 null 以 后 ， 沒有任何強引用指向threadlocal實例 ，只存在key的弱引用, 所 以Threadlocal() 將會被 gc 回收。

這樣一來， ThreadLocalMap 中就會出現 key 為 null 的 Entry，就沒有辦法訪問這些 key 為 null 的 Entry 的 value，如果當前 線程再遲遲不結束的話(如線程池)，這些 key 為 null 的Entry 的 value 就會一直存在一條強 引用鏈： Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value ，而這塊 value 永 遠不會被訪問到了，所以存在著內存泄露

只有當前 thread 結束以后， current thread 就不會存在棧中，強引用斷開， Current Thread 、Map

value 將全部被 GC 回收。

最好的做法是不在需要使用ThreadLocal 變量后，都調用它的 remove()方法，清除數據。

從表面上看內存泄漏的根源在于使用了弱引用， 但是另一個問題也同樣值得 思考：為什么使用弱引用而不是強引用？

我們分兩種情況討論：

key 使用強引用： 對 ThreadLocal 對象實例的引用被置為 null 了，但是ThreadLocalMap 還持有這個 ThreadLocal 對象實例的強引用， 如果沒有手動刪除， ThreadLocal 的對象實例不會被回收，導致 Entry 內存泄漏。

key 使用弱引用： 對 ThreadLocal 對象實例的引用被被置為 null 了，由于ThreadLocalMap 持有 ThreadLocal 的弱引用， 即使沒有手動刪除， ThreadLocal 的 對象實例也會被回收。value 在下一次 ThreadLocalMap 調用 set，get ，remove 都 有機會被回收。

比較兩種情況，我們可以發現：由于 ThreadLocalMap 的生命周期跟 Thread 一樣長， 如果都沒有手動刪除對應 key，都會導致內存泄漏， 但是使用弱引用可以多一層保障。

因此， ThreadLocal 內存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一樣長， 如果沒有手動刪除對應 key 就會導致內存泄漏， 而不是因為弱引用。

3.4 總結

JVM 利用設置 ThreadLocalMap 的 Key 為弱引用，來避免內存泄露。 JVM 利用調用 remove 、get、set 方法的時候，回收弱引用。

當 ThreadLocal 存儲很多 Key 為 null 的 Entry 的時候，而不再去調用 remove、 get 、set 方法，那

么將導致內存泄漏。

使用線程池+ ThreadLocal 時要小心， 因為這種情況下， 線程是一直在不斷的 重復運行的，從而也就造成了 value 可能造成累積的情況。