[[395368]]

前言

說(shuō)起ThreadLocal即便你沒(méi)有直接用到過(guò)，它也間接的出現(xiàn)在你使用過(guò)的框架里，比如Spring的事物管理，Hibernate的Session管理、logback(和log4j)中的MDC功能實(shí)現(xiàn)等。而在項(xiàng)目開(kāi)發(fā)中，比如用到的一些分頁(yè)功能的實(shí)現(xiàn)往往也會(huì)借助于ThreadLocal。

正是因?yàn)門(mén)hreadLocal的無(wú)處不在，所以在面試的時(shí)候也經(jīng)常會(huì)被問(wèn)到它的實(shí)現(xiàn)原理、核心API使用以及內(nèi)存泄露的問(wèn)題。

而且基于這些問(wèn)題還可以拓展到線程安全方面、JVM內(nèi)存管理與分析、Hash算法等等知識(shí)點(diǎn)。可見(jiàn)ThreadLocal對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是多么的重要的。如果你還沒(méi)有全面的了解，那么這篇文章值得你深入學(xué)習(xí)一下。

什么是ThreadLocal

ThreadLocal是Therad的局部變量的維護(hù)類(lèi)，在Java中是作為一個(gè)特殊的變量存儲(chǔ)在。當(dāng)使用ThreadLocal維護(hù)變量時(shí)，ThreadLocal為每個(gè)使用該變量的線程提供獨(dú)立的變量副本，所以每一個(gè)線程都可以獨(dú)立地改變自己的副本，而不會(huì)影響其它線程所對(duì)應(yīng)的副本。

因?yàn)槊總€(gè)Thread內(nèi)有自己的實(shí)例副本，且該副本只能由當(dāng)前Thread使用，也就不存在多線程間共享的問(wèn)題。

總的來(lái)說(shuō)，ThreadLocal適用于每個(gè)線程需要自己獨(dú)立的實(shí)例且該實(shí)例需要在多個(gè)方法中被使用，也即變量在線程間隔離而在方法或類(lèi)間共享的場(chǎng)景。

比如，有一個(gè)變量count，在多線程并發(fā)時(shí)操作count++會(huì)出現(xiàn)線程安全問(wèn)題。但是通過(guò)ThreadLocal就可以為每個(gè)線程創(chuàng)建只屬于當(dāng)前線程的count副本，各自操作各自的副本，不會(huì)影響到其他線程。

從另外一個(gè)角度來(lái)說(shuō)，ThreadLocal是一個(gè)數(shù)據(jù)結(jié)構(gòu)，有點(diǎn)像HashMap，可以保存"key:value"鍵值對(duì)，但是一個(gè)ThreadLocal只能保存一個(gè)鍵值對(duì)，各個(gè)線程的數(shù)據(jù)互不干擾。

@Test 
public void test1(){ 
    ThreadLocal<String> localName = new ThreadLocal<>(); 
    // 只提供了一個(gè)set方法； 
    localName.set("程序新視界"); 
    // 同時(shí)只提供了一個(gè)get方法 
    String name = localName.get(); 
    System.out.println(name); 
} 

上述代碼中線程A初始化了一個(gè)ThreadLocal對(duì)象，并調(diào)用set方法，保持了一個(gè)值。而這個(gè)值只能線程A調(diào)用get方法才能獲取到。如果此時(shí)線程B調(diào)用get方法是無(wú)法獲取到的。至于如何實(shí)現(xiàn)這一功能的，我們?cè)诤竺嬖创a分析中進(jìn)行講解，這里知道其功能即可。

ThreadLocal使用實(shí)例

上面介紹了使用場(chǎng)景和基本的實(shí)現(xiàn)理論，下面我們就來(lái)通過(guò)一個(gè)簡(jiǎn)單的實(shí)例看一下如何使用ThreadLocal。

public class ThreadLocalMain { 
 
    /** 
     * ThreadLocal變量，每個(gè)線程都有一個(gè)副本，互不干擾 
     */ 
    public static final ThreadLocal<String> HOLDER = new ThreadLocal<>(); 
 
    public static void main(String[] args) throws Exception { 
        new ThreadLocalMain().execute(); 
    } 
 
    public void execute() throws Exception { 
        // 主線程設(shè)置值 
        HOLDER.set("程序新視界"); 
        System.out.println(Thread.currentThread().getName() + "線程ThreadLocal中的值：" + HOLDER.get()); 
 
        new Thread(() -> { 
            System.out.println(Thread.currentThread().getName() + "線程ThreadLocal中的值：" + HOLDER.get()); 
            // 設(shè)置當(dāng)前線程中的值 
            HOLDER.set("《程序新視界》"); 
            System.out.println("重新設(shè)置之后，" + Thread.currentThread().getName() + "線程ThreadLocal中的值：" + HOLDER.get()); 
            System.out.println(Thread.currentThread().getName() + "線程執(zhí)行結(jié)束"); 
        }).start(); 
        // 等待所有線程執(zhí)行結(jié)束 
        Thread.sleep(1000L); 
        System.out.println(Thread.currentThread().getName() + "線程ThreadLocal中的值：" + HOLDER.get()); 
    } 
 
} 

示例中定義了一個(gè)static final的ThreadLocal變量HOLDER，在main方法中模擬通過(guò)兩個(gè)線程來(lái)操作HOLDER中存儲(chǔ)的值。先對(duì)HOLDER設(shè)置一個(gè)值，然后打印獲取得到的值，然后新起一個(gè)線程去修改HOLDER中的值，然后分別在新線程和主線程兩處獲取對(duì)應(yīng)的值。

執(zhí)行程序，打印結(jié)果如下：

main線程ThreadLocal中的值：程序新視界 
Thread-0線程ThreadLocal中的值：null 
重新設(shè)置之后，Thread-0線程ThreadLocal中的值：《程序新視界》 
Thread-0線程執(zhí)行結(jié)束 
main線程ThreadLocal中的值：程序新視界 

對(duì)照程序和輸出結(jié)果，你會(huì)發(fā)現(xiàn)，主線程和Thread-0各自獨(dú)享自己的變量存儲(chǔ)。主線程并沒(méi)有因?yàn)門(mén)hread-0調(diào)用了HOLDER的set方法而被改變。

之所以能達(dá)到這個(gè)效果，正是因?yàn)樵赥hreadLocal中，每個(gè)線程Thread擁有一份自己的副本變量，多個(gè)線程互不干擾。那么，你會(huì)疑惑，ThreadLocal是如何實(shí)現(xiàn)這一功能的呢?

ThreadLocal原理分析

在學(xué)習(xí)ThreadLocal的原理之前，我們先來(lái)看一些相關(guān)的理論知識(shí)和數(shù)據(jù)結(jié)構(gòu)。

基本流程與源碼實(shí)現(xiàn)

一個(gè)線程內(nèi)可以存多個(gè)ThreadLocal對(duì)象，存儲(chǔ)的位置位于Thread的ThreadLocal.ThreadLocalMap變量，在Thread中有如下變量：

/* ThreadLocal values pertaining to this thread. This map is maintained 
 * by the ThreadLocal class. */ 
ThreadLocal.ThreadLocalMap threadLocals = null; 

ThreadLocalMap是由ThreadLocal維護(hù)的靜態(tài)內(nèi)部類(lèi)，正如代碼中注解所說(shuō)這個(gè)變量是由ThreadLocal維護(hù)的。

我們?cè)谑褂肨hreadLocal的get()、set()方法時(shí)，其實(shí)都是調(diào)用了ThreadLocalMap類(lèi)對(duì)應(yīng)的get()、set()方法。

Thread中的這個(gè)變量的初始化通常是在首次調(diào)用ThreadLocal的get()、set()方法時(shí)進(jìn)行的。

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

上述set方法中，首先獲取當(dāng)前線程對(duì)象，然后通過(guò)getMap方法來(lái)獲取當(dāng)前線程中的threadLocals：

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

如果Thread中的對(duì)應(yīng)屬性為null，則創(chuàng)建一個(gè)ThreadLocalMap并賦值給Thread：

void createMap(Thread t, T firstValue) { 
    t.threadLocals = new ThreadLocalMap(this, firstValue); 
} 

如果已經(jīng)存在，則通過(guò)ThreadLocalMap的set方法設(shè)置值，這里我們可以看到set中key為this，也就是當(dāng)前ThreadLocal對(duì)象，而value值則是我們要存的值。

對(duì)應(yīng)的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(); 
} 

可以看到同樣通過(guò)當(dāng)前線程，拿到當(dāng)前線程的threadLocals屬性，然后從中獲取存儲(chǔ)的值并返回。在get的時(shí)候，如果Thread中的threadLocals屬性未進(jìn)行初始化，則也會(huì)間接調(diào)用createMap方法進(jìn)行初始化操作。

下面我們通過(guò)一個(gè)流程圖來(lái)匯總一下上述流程：

上述流程中給Thread的threadLocals屬性初始化的操作，在JDK8和9中通過(guò)debug發(fā)現(xiàn)，都沒(méi)有走createMap方法，暫時(shí)還不清楚JVM是如何進(jìn)行初始化賦值的。而在測(cè)試JDK13和JDK14的時(shí)候，很明顯走了createMap方法。

ThreadLoalMap的數(shù)據(jù)結(jié)構(gòu)

ThreadLoalMap是ThreadLocal中的一個(gè)靜態(tài)內(nèi)部類(lèi)，類(lèi)似HashMap的數(shù)據(jù)結(jié)構(gòu)，但并沒(méi)有實(shí)現(xiàn)Map接口。

ThreadLoalMap中初始化了一個(gè)大小16的Entry數(shù)組，Entry對(duì)象用來(lái)保存每一個(gè)key-value鍵值對(duì)。通過(guò)上面的set方法，我們已經(jīng)知道其中的key永遠(yuǎn)都是ThreadLocal對(duì)象。

看一下相關(guān)的源碼：

static class ThreadLocalMap { 
 
    static class Entry extends WeakReference<ThreadLocal<?>> { 
        /** The value associated with this ThreadLocal. */ 
        Object value; 
 
        Entry(ThreadLocal<?> k, Object v) { 
            super(k); 
            value = v; 
        } 
    } 
 
    private static final int INITIAL_CAPACITY = 16; 
 
    // ... 
} 

ThreadLoalMap的類(lèi)圖結(jié)構(gòu)如下：

這里需要留意的是，ThreadLocalMap類(lèi)中的Entry對(duì)象繼承自WeakReference，也就是說(shuō)它是弱引用。這里會(huì)出現(xiàn)內(nèi)存泄露的情況，后續(xù)會(huì)講到。

由于hreadLocalMaps是延遲創(chuàng)建的，因此在構(gòu)造時(shí)至少要?jiǎng)?chuàng)建一個(gè)Entry對(duì)象。這里可以從構(gòu)造方法中看到：

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

上述構(gòu)造方法，創(chuàng)建了一個(gè)默認(rèn)長(zhǎng)度為16的Entry數(shù)組，通過(guò)hashCode與length位運(yùn)算確定索引值i。而上面也提到，每個(gè)Thread都有一個(gè)ThreadLocalMap類(lèi)型的變量。

至此，結(jié)合Thread，我們可以看到整個(gè)數(shù)據(jù)模型如下：

hash沖突及解決

我們留意到構(gòu)造方法中Entry在table中存儲(chǔ)位置是通過(guò)hashcode算法獲得。每個(gè)ThreadLocal對(duì)象都有一個(gè)hash值threadLocalHashCode，每初始化一個(gè)ThreadLocal對(duì)象，hash值就增加一個(gè)固定的大小0x61c88647。

在向ThreadLocalMap中的Entry數(shù)值存儲(chǔ)Entry對(duì)象時(shí)，會(huì)根據(jù)ThreadLocal對(duì)象的hash值，定位到table中的位置i。這里分三種情況：

• 如果當(dāng)前位置為空的，直接將Entry存放在對(duì)應(yīng)位置;
• 如果位置i已經(jīng)有值且這個(gè)Entry對(duì)象的key正好是即將設(shè)置的key，那么重新設(shè)置Entry中的value;
• 如果位置i的Entry對(duì)象和即將設(shè)置的key沒(méi)關(guān)系，則尋找一個(gè)空位置;

計(jì)算hash值便會(huì)有hash沖突出現(xiàn)，常見(jiàn)的解決方法有：再哈希法、開(kāi)放地址法、建立公共溢出區(qū)、鏈?zhǔn)降刂贩ǖ取?/p>

上面的流程可以看出這里采用的是開(kāi)放地址方法，如果當(dāng)前位置有值，就繼續(xù)尋找下一個(gè)位置，注意table[len-1]的下一個(gè)位置是table[0]，就像是一個(gè)環(huán)形數(shù)組，所以也叫閉散列法。如果一直都找不到空位置就會(huì)出現(xiàn)死循環(huán)，發(fā)生內(nèi)存溢出。當(dāng)然有擴(kuò)容機(jī)制，一般不會(huì)找不到空位置的。

ThreadLocal內(nèi)存泄露

ThreadLocal使用不當(dāng)可能會(huì)出現(xiàn)內(nèi)存泄露，進(jìn)而可能導(dǎo)致內(nèi)存溢出。下面我們就來(lái)分析一下內(nèi)存泄露的原因及相關(guān)設(shè)計(jì)思想。

內(nèi)存引用鏈路

根據(jù)前面對(duì)ThreadLocal的分析，得知每個(gè)Thread維護(hù)一個(gè)ThreadLocalMap，它key是ThreadLocal實(shí)例本身，value是業(yè)務(wù)需要存儲(chǔ)的Object。也就是說(shuō)ThreadLocal本身并不存儲(chǔ)值，它只是作為一個(gè)key來(lái)讓線程從ThreadLocalMap獲取value。

仔細(xì)觀察ThreadLocalMap，這個(gè)map是使用ThreadLocal的弱引用作為Key的，弱引用的對(duì)象在GC時(shí)會(huì)被回收。因此使用了ThreadLocal后，引用鏈如圖所示：

其中虛線表示弱引用。下面我們先來(lái)了解一下Java中引用的分類(lèi)。

Java中的引用

Java中通常會(huì)存在以下類(lèi)型的引用：強(qiáng)引用、弱引用、軟引用、虛引用。

• 強(qiáng)引用：通常new出來(lái)的對(duì)象就是強(qiáng)引用類(lèi)型，只要引用存在，垃圾回收器將永遠(yuǎn)不會(huì)回收被引用的對(duì)象，哪怕內(nèi)存不足的時(shí)候;
• 軟引用：使用SoftReference修飾的對(duì)象被稱(chēng)為軟引用，軟引用指向的對(duì)象在內(nèi)存要溢出的時(shí)候被回收。如果回收之后，還沒(méi)有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常;
• 弱引用：使用WeakReference修飾的對(duì)象被稱(chēng)為弱引用，只要發(fā)生垃圾回收，無(wú)論當(dāng)前內(nèi)存是否足夠，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象實(shí)例。
• 虛引用：虛引用是最弱的引用，在Java中使用PhantomReference進(jìn)行定義。虛引用中唯一的作用就是用隊(duì)列接收對(duì)象即將死亡的通知。

泄露原因分析

正常來(lái)說(shuō)，當(dāng)Thread執(zhí)行完會(huì)被銷(xiāo)毀，Thread.threadLocals指向的ThreadLocalMap實(shí)例也隨之變?yōu)槔锩娲娣诺腅ntity也會(huì)被回收。這種情況是不會(huì)發(fā)生內(nèi)存泄漏的。

發(fā)生內(nèi)存泄露的場(chǎng)景一般存在于線程池的情況下。此時(shí)，Thread生命周期比較長(zhǎng)(存在循環(huán)使用)，threadLocals引用一直存在，當(dāng)其存放的ThreadLocal被回收(弱引用生命周期比較短)后，對(duì)應(yīng)的Entity就成了key為null的實(shí)例，但value值不會(huì)被回收。如果此Entity一直不被get()、set()、remove()，就一直不會(huì)被回收，也就發(fā)生了內(nèi)存泄漏。

所以，通常在使用完ThreadLocal后需要調(diào)用remove()方法進(jìn)行內(nèi)存的清除。

比如在web請(qǐng)求當(dāng)中，我們可以通過(guò)過(guò)濾器等進(jìn)行回收方法的調(diào)用：

public void doFilter(ServeletRequest request, ServletResponse){ 
    try{ 
        //設(shè)置ThreadLocal變量 
        localName.set("程序新視界"); 
        chain.doFilter(request, response) 
    }finally{ 
        //調(diào)用remove方法溢出threadLocal中的變量 
        localName.remove(); 
    } 
} 

為什么使用弱引用而不是強(qiáng)引用?

從表面上看內(nèi)存泄漏的根源在于使用了弱引用，但為什么JDK采用了弱引用的實(shí)現(xiàn)而不是強(qiáng)引用呢?

先來(lái)看ThreadLocalMap類(lèi)上的一段注釋?zhuān)?/p>

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.  
 
為了協(xié)助處理數(shù)據(jù)比較大并且生命周期比較長(zhǎng)的場(chǎng)景，hash table的條目使用了WeakReference作為key。 

為了協(xié)助處理數(shù)據(jù)比較大并且生命周期比較長(zhǎng)的場(chǎng)景，hash table的條目使用了WeakReference作為key。

這跟我們想象的有些不同，弱引用反而是為了解決內(nèi)存存儲(chǔ)問(wèn)題而專(zhuān)門(mén)使用的。

我們先來(lái)假設(shè)一下，如果key使用強(qiáng)引用，那么在其他持有ThreadLocal引用的對(duì)象都回收了，但ThreadLocalMap依舊持有ThreadLocal的強(qiáng)引用，這就導(dǎo)致ThreadLocal不會(huì)被回收，從而導(dǎo)致Entry內(nèi)存泄露。

對(duì)照一下，弱引用的情況。持有ThreadLocal引用的對(duì)象都回收了，ThreadLocalMap持有的是ThreadLocal的弱引用，會(huì)被自動(dòng)回收。只不過(guò)對(duì)應(yīng)的value值，需要在下次調(diào)用set/get/remove方法時(shí)會(huì)被清除。

綜合對(duì)比會(huì)發(fā)現(xiàn)，采用弱引用反而多了一層保障，ThreadLocal被清理后key為null，對(duì)應(yīng)的value在下一次ThreadLocalMap調(diào)用set、get、remove的時(shí)候可能會(huì)被清除。

所以，內(nèi)存泄露的根本原因是是否手動(dòng)清除操作，而不是弱引用。

ThreadLocal應(yīng)用場(chǎng)景

最后，我們?cè)賮?lái)回顧一下ThreadLocal的應(yīng)用場(chǎng)景：

• 線程間數(shù)據(jù)隔離，各線程的ThreadLocal互不影響;
• 方便同一個(gè)線程使用某一對(duì)象，避免不必要的參數(shù)傳遞;
• 全鏈路追蹤中的traceId或者流程引擎中上下文的傳遞一般采用ThreadLocal;
• Spring事務(wù)管理器采用了ThreadLocal;
• Spring MVC的RequestContextHolder的實(shí)現(xiàn)使用了ThreadLocal;

小結(jié)

本篇文章我們從ThreadLocal的使用場(chǎng)景、源碼、類(lèi)結(jié)構(gòu)、內(nèi)存結(jié)構(gòu)等進(jìn)行分析說(shuō)明，最后分析了其引起內(nèi)存泄露的根本原因。通過(guò)本篇文章的學(xué)習(xí)，基本上能掌握ThreadLocal百分之百九十的核心知識(shí)點(diǎn)。你學(xué)到了嗎?