本文 github/SmileLionCoder 已收錄，有Java程式員進階技術知識地圖以及我的系列文章，歡迎大家Star，

ThreadLocal使用不規范，師傅兩行淚

組內來了一個實習生，看這小伙子春光滿面、精神抖擻、頭發微少，我心頭一喜：絕對是個潛力股，于是我找經理申請親自來帶他，為了幫助小伙子快速成長，我給他分了一個需求，這不需求剛上線幾天就出網上問題了😭后臺監控服務發現記憶體一直在緩慢上升，初步懷疑是記憶體泄露，

把實習生的PR都找出來仔細review，果然發現問題了，由于公司內部代碼是保密的，這里簡單寫一個demo還原場景（忽略代碼風格問題），

public class ThreadPoolDemo {
    private static final ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>());
    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 100; ++i) {
            poolExecutor.execute(new Runnable() {
                @Override
                public void run() {
                    ThreadLocal<BigObject> threadLocal = new ThreadLocal<>();
                    threadLocal.set(new BigObject());
                    // 其他業務代碼
                }
            });
            Thread.sleep(1000);
        }
    }
    static class BigObject {
        // 100M
        private byte[] bytes = new byte[100 * 1024 * 1024];
    }
}

代碼分析：

創建一個核心執行緒數和最大執行緒數都為10的執行緒池，保證執行緒池里一直會有10個執行緒在運行，
使用for回圈向執行緒池中提交了100個任務，
定義了一個ThreadLocal型別的變數，Value型別是大物件，
每個任務會向threadLocal變數里塞一個大物件，然后執行其他業務邏輯，
由于沒有呼叫執行緒池的shutdown方法，執行緒池里的執行緒還是會在運行，

乍一看這代碼好像沒有什么問題，那為什么會導致服務GC后記憶體還高居不下呢？

代碼中給threadLocal賦值了一個大的物件，但是執行完業務邏輯后沒有呼叫remove方法，最后導致執行緒池中10個執行緒的threadLocals變數中包含的大物件沒有被釋放掉，出現了記憶體泄露，

大家說說這樣的實習生還能留不？

ThreadLocal的value值存在哪里？

實習生說他以為執行緒任務結束了threadLocal賦值的物件會被JVM垃圾回收，很疑惑為什么會出現記憶體泄露，作為師傅我肯定要給他把原理講透呀，

ThreadLocal類提供set/get方法存盤和獲取value值，但實際上ThreadLocal類并不存盤value值，真正存盤是靠ThreadLocalMap這個類，ThreadLocalMap是ThreadLocal的一個靜態內部類，它的key是ThreadLocal實體物件，value是任意Object物件，

ThreadLocalMap類的定義

static class ThreadLocalMap {
    // 定義一個table陣列，存盤多個threadLocal物件及其value值
    private Entry[] table;
    ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
        table = new Entry[INITIAL_CAPACITY];
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        table[i] = new Entry(firstKey, firstValue);
        size = 1;
        setThreshold(INITIAL_CAPACITY);
    }
    // 定義一個Entry類，key是一個弱參考的ThreadLocal物件
    // value是任意物件
    static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value;
        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }
    // 省略其他
}

進一步分析ThreadLocal類的代碼，看set和get方法如何與ThreadLocalMap靜態內部類關聯上，

ThreadLocal類set方法

public class ThreadLocal<T> {
 public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

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

    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }
    // 省略其他方法
}

set的邏輯比較簡單，就是獲取當前執行緒的ThreadLocalMap，然后往map里添加KV，K是當前ThreadLocal實體，V是我們傳入的value，這里需要注意一下，map的獲取是需要從Thread類物件里面取，看一下Thread類的定義，

public class Thread implements Runnable {
    ThreadLocal.ThreadLocalMap threadLocals = null;
    //省略其他
}

Thread類維護了一個ThreadLocalMap的變數參考，

ThreadLocal類get方法

get獲取當前執行緒的對應的私有變數，是之前set或者通過initialValue的值，代碼如下：

class ThreadLocal<T> {
    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;
        }
        return setInitialValue();
    }
}

代碼邏輯分析：

獲取當前執行緒的ThreadLocalMap實體；
如果不為空，以當前ThreadLocal實體為key獲取value；
如果ThreadLocalMap為慷訓者根據當前ThreadLocal實體獲取的value為空，則執行setInitialValue()；

ThreadLocal相關類的關系總結

看了上面的分析是不是對Thread，ThreadLocal，ThreadLocalMap，Entry這幾個類之間的關系有點暈了，沒關系我專門畫了一個UML類圖來總結（忽略UML標準語法），

ThreadLocal相關類的關系

每個執行緒是一個Thread實體，其內部維護一個threadLocals的實體成員，其型別是ThreadLocal.ThreadLocalMap，
通過實體化ThreadLocal實體，我們可以對當前運行的執行緒設定一些執行緒私有的變數，通過呼叫ThreadLocal的set和get方法存取，
ThreadLocal本身并不是一個容器，我們存取的value實際上存盤在ThreadLocalMap中，ThreadLocal只是作為TheadLocalMap的key，
每個執行緒實體都對應一個TheadLocalMap實體，我們可以在同一個執行緒里實體化很多個ThreadLocal來存盤很多種型別的值，這些ThreadLocal實體分別作為key，對應各自的value，最終存盤在Entry table陣列中，
當呼叫ThreadLocal的set/get進行賦值/取值操作時，首先獲取當前執行緒的ThreadLocalMap實體，然后就像操作一個普通的map一樣，進行put和get，

ThreadLocal記憶體模型原理

經過上面的分析我們對ThreadLocal相關的類設計已經非常清楚了，下面通過一張圖更加深入理解一下ThreadLocal的記憶體存盤，

ThreadLocal記憶體模型

圖中左邊是堆疊，右邊是堆，執行緒的一些區域變數和參考使用的記憶體屬于Stack（堆疊）區，而普通的物件是存盤在Heap（堆）區，

執行緒運行時，我們定義的TheadLocal物件被初始化，存盤在Heap，同時執行緒運行的堆疊區保存了指向該實體的參考，也就是圖中的ThreadLocalRef，
當ThreadLocal的set/get被呼叫時，虛擬機會根據當前執行緒的參考也就是CurrentThreadRef找到其對應在堆區的實體，然后查看其對用的TheadLocalMap實體是否被創建，如果沒有，則創建并初始化，
Map實體化之后，也就拿到了該ThreadLocalMap的句柄，那么就可以將當前ThreadLocal物件作為key，進行存取操作，
圖中的虛線，表示key對應ThreadLocal實體的參考是個弱參考，

強參考弱參考的概念

ThreadLocalMap的key是一個弱參考型別，源代碼如下：

static class ThreadLocalMap {
    // 定義一個Entry類，key是一個弱參考的ThreadLocal物件
    // value是任意物件
    static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value;
        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }
    // 省略其他
}

下面解釋一下常見的幾種參考概念，

強參考

一直活著：類似“Object obj=new Object()”這類的參考，只要強參考還存在，垃圾收集器永遠不會回收掉被參考的物件實體，

弱參考

回收就會死亡：被弱參考關聯的物件實體只能生存到下一次垃圾收集發生之前，當垃圾收集器作業時，無論當前記憶體是否足夠，都會回收掉只被弱參考關聯的物件實體，在JDK 1.2之后，提供了WeakReference類來實作弱參考，

軟參考

有一次活的機會：軟參考關聯著的物件，在系統將要發生記憶體溢位例外之前，將會把這些物件實體列進回收范圍之中進行第二次回收，如果這次回識訓沒有足夠的記憶體，才會拋出記憶體溢位例外，在JDK 1.2之后，提供了SoftReference類來實作軟參考，

虛參考

也稱為幽靈參考或者幻影參考，它是最弱的一種參考關系，一個物件實體是否有虛參考的存在，完全不會對其生存時間構成影響，也無法通過虛參考來取得一個物件實體，為一個物件設定虛參考關聯的唯一目的就是能在這個物件實體被收集器回收時收到一個系統通知，在JDK 1.2之后，提供了PhantomReference類來實作虛參考，

記憶體泄露是不是弱參考的鍋？

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

翻看官網檔案的說法：

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

為了處理非常大和長期的用途，哈希表條目使用weakreference作為鍵，

分兩種情況討論：

（1）key 使用強參考

參考ThreadLocal的物件被回收了，但是ThreadLocalMap還持有ThreadLocal的強參考，如果沒有手動洗掉，ThreadLocal不會被回收，導致Entry記憶體泄漏，

（2）key 使用弱引

參考ThreadLocal的物件被回收了，由于ThreadLocalMap持有ThreadLocal的弱參考，即使沒有手動洗掉，ThreadLocal也會被回收，value在下一次ThreadLocalMap呼叫set、get、remove的時候會被清除，

比較兩種情況，我們可以發現：由于ThreadLocalMap的生命周期跟Thread一樣長，如果都沒有手動洗掉對應key，都會導致記憶體泄漏，但是使用弱參考可以多一層保障：弱參考ThreadLocal被清理后key為null，對應的value在下一次ThreadLocalMap呼叫set、get、remove的時候可能會被清除，

因此，ThreadLocal記憶體泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一樣長，如果沒有手動洗掉對應key就會導致記憶體泄漏，而不是因為弱參考，

ThreadLocal最佳實踐

通過前面幾小節我們分析了ThreadLocal的類設計以及記憶體模型，同時也重點分析了發生記憶體泄露的條件和特定場景，最后結合專案中的經驗給出建議使用ThreadLocal的場景：

當需要存盤執行緒私有變數的時候，
當需要實作執行緒安全的變數時，
當需要減少執行緒資源競爭的時候，

綜合上面的分析，我們可以理解ThreadLocal記憶體泄漏的前因后果，那么怎么避免記憶體泄漏呢？

答案就是：每次使用完ThreadLocal，建議呼叫它的remove()方法，清除資料，

另外需要強調的是并不是所有使用ThreadLocal的地方，都要在最后remove（），因為他們的生命周期可能是需要和專案的生存周期一樣長的，所以要進行恰當的選擇，以免出現業務邏輯錯誤！

-- END --

日常求贊：你好技術人，先贊后看養成習慣，你的贊是我前進道路上的動力，對我非常重要，

加油技術人！

簡介：博主從華中科技大學碩士畢業，是一個對技術有追求，對生活有激情的程式員，幾年間浪跡于多個一線互聯網大廠，具有多年開發實戰經驗，

微信搜索公眾號【愛笑的架構師】，我有技術和故事，等你來，

文章持續更新，在 github/SmileLionCoder 中可以看到我歸檔的系列文章，有面試經驗和技術干貨，歡迎Star，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/197258.html

標籤：其他

上一篇：苦熬一個月，整出這份“架構腦圖 / 面試決議 / 進階知識 ”全都有的Spring全家桶

下一篇：XSS是什么？如何防御？手摸手教你Springboot配置XSS防御，深入代碼決議！

記憶體泄露的原因找到了，罪魁禍首居然是Java TheadLocal