你好，我是坤哥

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

問題簡述

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

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

// 開啟多線程處理
new Thread(new Runnable() {
    @Override
    public void run() {
        Map clientInfoMap = Context.getContext().getClientInfo();
          // 無法獲取客戶端信息，返回需要升級的信息
          if (clientInfoMap == null) {
            throw new Exception("版本號過低，請升級版本");
        }
        String version = clientInfoMap.get("version");


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

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

那么問題來了，改成多線程后客戶端信息怎么就取不到了呢？要搞清楚這個問題，就得先了解客戶端信息是如何存儲的了。

Threadlocal 簡介

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

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

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

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

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

無鎖化

ThreadLocal 即線程本地變量，它可以為每個線程創(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);
}

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

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

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

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

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

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

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

它與 HashMap 類似，存儲的都是鍵值對，只不過每一項（Entry）中的 key 為 threadlocal 變量（如上文案例中的 threadLocal1），value 才為我們要存儲的值（如上文中的 SimpleDateFormat 實例）,此外它們在碰到 hash 沖突時的處理策略也不同，HashMap 在碰到 hash 沖突時采用的是鏈表法，而 ThreadLocalMap 采用的是線性探測法。

2.簡化變量的傳遞邏輯

接下來我們來看使用 ThreadLocal 的等二個好處，簡化變量的傳遞邏輯，線程在處理業(yè)務(wù)邏輯時可能會調(diào)用幾十個方法，如果這些方法中只有幾個需要用到 clientInfo，難道要在這幾十個方法中定義一個 clientInfo 參數(shù)來層層傳遞嗎，顯然不現(xiàn)實。那該怎么辦呢，使用 ThreadLocal 即可解決此問題。由上文可知通過 ThreadLocal 設(shè)置的本地變量是同 threadlocal 一起保存在 Thread 的 ThreadLocalMap 這個內(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();
    }
}

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

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

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; // 請求頭信息
      private Map<String, Map<String, String>> cookies = null; // 請求 cookie

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

}

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

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

問題剖析

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

public class ThreadLocal<T> {
        public T get() {
        // 1.先獲取當前線程
        Thread t = Thread.currentThread();
          // 2.再獲取當前線程的 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. 首先需要獲取當前線程
2. 其次獲取當前線程的 ThreadLocalMap
3. 進而再去獲取相應(yīng)的本地變量值
4. 如果沒有的話則調(diào)用 initiaValue 方法來初始化本地變量

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

解決方案

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

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

// 先從當前線程的 Context 中獲取 clientInfo
Map clientInfoMap = Context.getContext().getClientInfo();
new Thread(new Runnable() {
    @Override
    public void run() {
                // 此時的 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() {
                // 此時的 clientInfo 能正常獲取到
        Map clientInfo = Context.getContext().getClientInfo();
        String version = clientInfo.get("version");
        // 以下正常邏輯
        ....
    }
}).start();

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

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

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 其實是繼承自 ThreadLocal 類的，此外我們在 getMap 和 createMap 這兩個方法中也發(fā)現(xiàn)它的底層其實是用 inheritableThreadLocals 來存儲的，而 ThreadLocal 用的是 threadLocals 變量存儲的。

public class Thread implements Runnable {
    // ThreadLocal 實例的底層存儲
    ThreadLocal.ThreadLocalMap threadLocals = null;

      // inheritableThreadLocals 實例的底層存儲
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
}

知道了這些，我們再來看下創(chuàng)建線程時涉及到的 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)
              // 將當前線程的 inheritableThreadLocals 復(fù)制給新創(chuàng)建線程的 inheritableThreadLocals
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
    }
}

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

總結(jié)

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

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