你好，我是坤哥

前些日子我們線上出現(xiàn)了一個(gè)比較嚴(yán)重的故障，這個(gè)故障是多線程使用不當(dāng)引起的，挺有代表性的，所以分享給大家，希望能幫大家避坑。

問(wèn)題簡(jiǎn)述

先簡(jiǎn)單介紹一下問(wèn)題產(chǎn)生的背景，我們有個(gè)返利業(yè)務(wù)，其中有個(gè)搜索場(chǎng)景，這個(gè)場(chǎng)景是用戶在 app 輸入搜索關(guān)鍵詞，然后 server 會(huì)根據(jù)這個(gè)關(guān)鍵詞到各個(gè)平臺(tái)（如淘寶，京東，拼多多等）調(diào)一下搜索接口，聚合這些搜索結(jié)果后再返回給用戶，最開(kāi)始這個(gè)搜索場(chǎng)景處理是單線程的，但隨著接入的平臺(tái)越來(lái)越多，搜索請(qǐng)求耗時(shí)也越來(lái)越長(zhǎng)，由于每個(gè)平臺(tái)的搜索請(qǐng)求都是獨(dú)立的，很顯然，單線程是可以優(yōu)化為多線程的，如下：

這樣的話，搜索請(qǐng)求的耗時(shí)就只取決于搜索接口耗時(shí)最長(zhǎng)的那個(gè)平臺(tái)，所以使用多線程顯然對(duì)接口性能是一個(gè)極大的優(yōu)化，但使用多線程改造上線后，短時(shí)間內(nèi)社群中有多名用戶反饋前臺(tái)展示「APP 需要升級(jí)的提示」，經(jīng)定位后發(fā)現(xiàn)是因?yàn)樵诙嗑€程中無(wú)法獲取客戶端信息，由于客戶端信息缺失，導(dǎo)致返回給用戶需要升級(jí)的提示，偽代碼如下：

// 開(kāi)啟多線程處理
new Thread(new Runnable() {
    @Override
    public void run() {
        Map clientInfoMap = Context.getContext().getClientInfo();
          // 無(wú)法獲取客戶端信息，返回需要升級(jí)的信息
          if (clientInfoMap == null) {
            throw new Exception("版本號(hào)過(guò)低，請(qǐng)升級(jí)版本");
        }
        String version = clientInfoMap.get("version");


        // 以下正常邏輯
        ....
    }
}).start();

畫外音：在生產(chǎn)中多線程使用的是線程池來(lái)實(shí)現(xiàn)，這里為了方便演示，直接 new Thread，效果都一樣，大家知道即可。

那么問(wèn)題來(lái)了，改成多線程后客戶端信息怎么就取不到了呢？要搞清楚這個(gè)問(wèn)題，就得先了解客戶端信息是如何存儲(chǔ)的了。

Threadlocal 簡(jiǎn)介

不同客戶端請(qǐng)求的客戶端信息（wifi 還是 4G，機(jī)型，app名稱，電量等）顯然不一樣，dubbo 業(yè)務(wù)線程拿到客戶端請(qǐng)求后首先會(huì)將有用的請(qǐng)求信息提取出來(lái)（如本文中的 Map clientInfo），但這個(gè) clientInfo 可能會(huì)在線程調(diào)用的各個(gè)方法中用到，于是如何存儲(chǔ)就成為了一個(gè)現(xiàn)實(shí)的問(wèn)題，相信有經(jīng)驗(yàn)的朋友一下就想到了，沒(méi)錯(cuò)，用 Threadlocal ！為什么用它，它有什么優(yōu)勢(shì)，簡(jiǎn)單來(lái)說(shuō)有兩點(diǎn)：

1. 無(wú)鎖化提升并發(fā)性能
2. 簡(jiǎn)化變量的傳遞邏輯

1.無(wú)鎖化提升并發(fā)性能

先說(shuō)第一個(gè)，無(wú)鎖化提升并發(fā)性能，影響并發(fā)的原因有很多，其中一個(gè)很重要的原因就是鎖，為了防止對(duì)共享變量的競(jìng)用，不得不對(duì)共享變量加鎖。

如果對(duì)共享變量爭(zhēng)用的線程數(shù)增多，顯然會(huì)嚴(yán)重影響系統(tǒng)的并發(fā)度，最好的辦法就是使用“影分身術(shù)”為每個(gè)線程都創(chuàng)建一個(gè)線程本地變量，這樣就避免了對(duì)共享變量的競(jìng)用，也就實(shí)現(xiàn)了無(wú)鎖化。

無(wú)鎖化

ThreadLocal 即線程本地變量，它可以為每個(gè)線程創(chuàng)建一份線程本地變量，使用方法如下：

static ThreadLocal<SimpleDateFormat> threadLocal1 = new ThreadLocal<SimpleDateFormat>() {
    @Override
    protected SimpleDateFormat initialValue() {
        return new SimpleDateFormat("yyyy-MM-dd");
    }
};

public String formatDate(Date date) {
    return threadLocal1.get().format(date);
}

這樣的話每個(gè)線程就獨(dú)享一份與其他線程無(wú)關(guān)的 SimpleDateFormat 實(shí)例副本，它們調(diào)用 formatDate 時(shí)使用的 SimpleDateFormat 實(shí)例也是自己獨(dú)有的副本，無(wú)論對(duì)副本怎么操作對(duì)其他線程都互不影響。

通過(guò)以上例子我們可以看出，可以通過(guò) new ThreadLocal+ initialValue 來(lái)為創(chuàng)建的 ThreadLocal 實(shí)例初始化本地變量（initialValue 方法會(huì)在首次調(diào)用 get 時(shí)被調(diào)用以初始化本地變量）。當(dāng)然，如果之后需要修改本地變量的話，也可以用以下方式來(lái)修改。

threadLocal1.set(new SimpleDateFormat("yyyy-MM-dd"))

而使用 threadLocal1.get()這樣的方法即可獲得線程本地變量。

可能一些朋友會(huì)好奇線程本地變量是如何存儲(chǔ)的，一圖勝千言。

每一個(gè)線程（Thread）內(nèi)部都有一個(gè) ThreadLocalMap, ThreadLocal 的 get 和 set 操作其實(shí)在底層都是針對(duì) ThreadLocalMap 進(jìn)行操作的。

public class Thread implements Runnable {
    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

它與 HashMap 類似，存儲(chǔ)的都是鍵值對(duì)，只不過(guò)每一項(xiàng)（Entry）中的 key 為 threadlocal 變量（如上文案例中的 threadLocal1），value 才為我們要存儲(chǔ)的值（如上文中的 SimpleDateFormat 實(shí)例）,此外它們?cè)谂龅?hash 沖突時(shí)的處理策略也不同，HashMap 在碰到 hash 沖突時(shí)采用的是鏈表法，而 ThreadLocalMap 采用的是線性探測(cè)法。

2.簡(jiǎn)化變量的傳遞邏輯

接下來(lái)我們來(lái)看使用 ThreadLocal 的等二個(gè)好處，簡(jiǎn)化變量的傳遞邏輯，線程在處理業(yè)務(wù)邏輯時(shí)可能會(huì)調(diào)用幾十個(gè)方法，如果這些方法中只有幾個(gè)需要用到 clientInfo，難道要在這幾十個(gè)方法中定義一個(gè) clientInfo 參數(shù)來(lái)層層傳遞嗎，顯然不現(xiàn)實(shí)。那該怎么辦呢，使用 ThreadLocal 即可解決此問(wèn)題。由上文可知通過(guò) ThreadLocal 設(shè)置的本地變量是同 threadlocal 一起保存在 Thread 的 ThreadLocalMap 這個(gè)內(nèi)部類中的，所以可在線程調(diào)用的任意方法中取出，偽代碼如下：

public class ThreadLocalWithUserContext implements Runnable {

    private static ThreadLocal<Map<String,String>> threadLocal 
      = new ThreadLocal<>();

    @Override
    public void run() {
                // clientInfo 初始化
        Map<String, String> clientInfo = xxx;
        threadLocal.set(clientInfo);
          test1();
    }

      public void test1() {
                test2(); 
    }

    public void test2() {
        testX();
    }
      ...

    public void testX() {
                Map clientInfo = threadLocal.get();
    }
}

中間定義的任何方法都無(wú)需為了傳遞 clientInfo 而定義一個(gè)額外的變量，代碼優(yōu)雅了不少。

由以上分析可知，使用 ThreadLocal 確實(shí)比較方便，在此我們先停下來(lái)思考一個(gè)問(wèn)題：如果線程在調(diào)用過(guò)程中只用到一個(gè) clientInfo 這樣的信息，只定義一個(gè) ThreadLocal 變量當(dāng)然就夠了，但實(shí)際上在使用過(guò)程中我們可能要傳遞多個(gè)類似 clientInfo 這樣的信息（如 userId，cookie，header），難道因此要定義多個(gè) ThreadLocal 變量嗎，這么做不是不可以，但不夠優(yōu)雅，更合適的做法是我們只定義一個(gè) ThreadLocal 變量，變量存的是一個(gè)上下文對(duì)象，其他像 clientInfo，userId，header 等信息就作為此上下文對(duì)象的屬性即可，代碼如下：

public final class Context {

    private static final ThreadLocal<Context> LOCAL = new ThreadLocal<Context>() {
        protected Context initialValue() {
            return new Context();
        }
    };


      private Long uid;     // 用戶uid
      private Map<String, String> clientInfo; // 客戶端信息
      private Map<String, String> headers = null; // 請(qǐng)求頭信息
      private Map<String, Map<String, String>> cookies = null; // 請(qǐng)求 cookie

      public static Context getContext() {
        return (Context) LOCAL.get();
    }

}

這樣的話我們可通過(guò) Context.getContext().getXXX() 的形式來(lái)獲取線程所需的信息，通過(guò)這樣的方式我們不僅避免了定義無(wú)數(shù) ThreadLocal 變量的煩惱，而且還收攏了上下文信息的管理。

通過(guò)以上介紹相信大家也都知道了 clientInfo 其實(shí)是借由 ThreadLocal 存儲(chǔ)的，認(rèn)清了這個(gè)事實(shí)后那我們現(xiàn)在再回頭看開(kāi)頭的生產(chǎn)問(wèn)題：將單線程改成多線程后，為什么在新線程中就拿不到 clientInfo 了？

問(wèn)題剖析

源碼之下無(wú)秘密，我們查看一下源碼來(lái)一探究竟，獲取本地變量的值使用的是 ThreadLocal.get 方法，那就來(lái)看下這個(gè)方法。

public class ThreadLocal<T> {
        public T get() {
        // 1.先獲取當(dāng)前線程
        Thread t = Thread.currentThread();
          // 2.再獲取當(dāng)前線程的 ThreadLocalMap
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }
}

可以看到 get 方法主要步驟如下：

1. 首先需要獲取當(dāng)前線程
2. 其次獲取當(dāng)前線程的 ThreadLocalMap
3. 進(jìn)而再去獲取相應(yīng)的本地變量值
4. 如果沒(méi)有的話則調(diào)用 initiaValue 方法來(lái)初始化本地變量

由此可知當(dāng)我們調(diào)用 threadlocal.get  時(shí)，會(huì)拿到當(dāng)前線程的 ThreadLocalMap，然后再去拿 entry 中的本地變量，而對(duì)多線程來(lái)說(shuō)，新線程的 ThreadLocalMap 里面的東西本來(lái)就未做任何設(shè)置，是空的，拿不到線程本地變量也就合情合理了。

解決方案

問(wèn)題清楚了，那怎么解決呢，不難得知主要有兩種方案：

1.我們之前是在新線程的執(zhí)行方法中調(diào)用 threadlocal.get 方法，可以改成先從當(dāng)前執(zhí)行線程中調(diào)用 threadlocal.get 獲得 clientInfo，然后再把 clientInfo 傳入新線程，偽代碼如下：

// 先從當(dāng)前線程的 Context 中獲取 clientInfo
Map clientInfoMap = Context.getContext().getClientInfo();
new Thread(new Runnable() {
    @Override
    public void run() {
                // 此時(shí)的 clientInfoMap 由于是在新線程創(chuàng)建前獲取的，肯定是有值的
        String version = clientInfoMap.get("version");


        // 以下正常邏輯
        ....
    }
}).start();

2.只需把 ThreadLocal 換成 InheritableThreadLocal，如下：

public final class Context {
    private static final InheritableThreadLocal<Context> LOCAL = new InheritableThreadLocal<Context>() {
        protected Context initialValue() {
            return new Context();
        }
    };

      public static Context getContext() {
        return (Context) LOCAL.get();
    }
}

new Thread(new Runnable() {
    @Override
    public void run() {
                // 此時(shí)的 clientInfo 能正常獲取到
        Map clientInfo = Context.getContext().getClientInfo();
        String version = clientInfo.get("version");
        // 以下正常邏輯
        ....
    }
}).start();

為什么 InheritableThreadLocal 能有這么神奇，背后的原理是什么?

由前文介紹我們得知，ThreadLocal 變量最終是存在 ThreadLocalMap 中的，那么能否在創(chuàng)建新線程的時(shí)候，把當(dāng)前線程的 ThreadLocalMap 復(fù)制給新線程的 ThreadLocalMap 呢，這樣的話即便你從新線程中調(diào)用 threadlocal.get 也照樣能獲得對(duì)應(yīng)的本地變量，和 InheritableThreadLocal 相關(guān)的底層干的就是這個(gè)事，我們先來(lái)瞧一瞧 InheritableThreadLocal 長(zhǎng)啥樣。

public class InheritableThreadLocal<T> extends ThreadLocal<T> {

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

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

由此可知 InheritableThreadLocal 其實(shí)是繼承自 ThreadLocal 類的，此外我們?cè)?getMap 和 createMap 這兩個(gè)方法中也發(fā)現(xiàn)它的底層其實(shí)是用 inheritableThreadLocals 來(lái)存儲(chǔ)的，而 ThreadLocal 用的是 threadLocals 變量存儲(chǔ)的。

public class Thread implements Runnable {
    // ThreadLocal 實(shí)例的底層存儲(chǔ)
    ThreadLocal.ThreadLocalMap threadLocals = null;

      // inheritableThreadLocals 實(shí)例的底層存儲(chǔ)
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
}

知道了這些，我們?cè)賮?lái)看下創(chuàng)建線程時(shí)涉及到的 inheritableThreadLocals 復(fù)制相關(guān)的關(guān)鍵代碼如下：

public
class Thread implements Runnable {
    public Thread() {
        init(null, null, "Thread-" + nextThreadNum(), 0);
    }

    private void init(ThreadGroup g, Runnable target, String name,
                      long stackSize) {
        init(g, target, name, stackSize, null, true);
    }

    private void init(ThreadGroup g, Runnable target, String name,
                      long stackSize, AccessControlContext acc,
                      boolean inheritThreadLocals) {
          ...
          Thread parent = currentThread();
        if (inheritThreadLocals && parent.inheritableThreadLocals != null)
              // 將當(dāng)前線程的 inheritableThreadLocals 復(fù)制給新創(chuàng)建線程的 inheritableThreadLocals
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
    }
}

由此可知，在創(chuàng)建新線程時(shí)，在初始化時(shí)其實(shí)相關(guān)邏輯是幫我們干了復(fù)制 inheritableThreadLocals 的操作，至此真相大白。

總結(jié)

看完本文，相信大家對(duì) Threadlocal 與 InheritableThreadLocal 的使用及其底層原理的掌握已不存在疑問(wèn)，這也提醒我們熟練地掌握一個(gè)組件或一項(xiàng)技術(shù)最好的方式還是熟讀它的源碼，畢竟源碼之下無(wú)秘密，當(dāng)我們使用到別人封裝好的組件或類時(shí)，如果有興趣也可以也看一下它的源碼，以本文為例，其實(shí)我們工程中多處地方都使用了 Context.getContext().getClientInfo();這樣的獲取客戶端信息的形式，用慣了導(dǎo)致在多線程環(huán)境下沒(méi)有引起警惕，以致踩了坑。

另外需要注意的是 ThreadLocal 使用不當(dāng)可能導(dǎo)致內(nèi)存泄漏，需要在線程結(jié)束后及時(shí) remove 掉，這些技術(shù)細(xì)節(jié)不是本文重點(diǎn)，故而沒(méi)有深入詳解，有興趣的大家可以去查閱相關(guān)資料。