切換語言為:簡體

竟然有90%的ThreadLocal都在濫用或錯用!

  • 爱糖宝
  • 2024-08-23
  • 2053
  • 0
  • 0

最近在看一個系統程式碼時,發現系統裡面在使用到了 ThreadLocal,乍一看,好像很高階的樣子。我再仔細一看,這個場景並不會存線上程安全問題,完全只是在一個方法中傳參使用的啊!(震驚)

難道是我水平太低,看不懂這個高階用法?經過和架構師請教和確認,這完全就是一個 ThreadLocal 濫用的典型案例啊!甚至,日常的業務系統中,90%以上的 ThreadLocal 都在濫用或錯用!快來看看說的是不是你~

ThreadLocal 簡介

ThreadLocal 也叫執行緒區域性變數,是 Java 提供的一個工具類,它為每個執行緒提供一個獨立的變數副本,從而實現執行緒間的資料隔離

ThreadLocal 中的關鍵方法如下:

方法定義 方法用途
public T get() 返回當前執行緒所對應執行緒區域性變數
public void set(T value) 設定當前執行緒的執行緒區域性變數的值
public void remove() 刪除當前執行緒區域性變數的值

濫用:無傷大雅

在一些沒有必要進行執行緒隔離的場景中使用“好像高階”的 ThreadLocal,看起來是挺唬人的,但這其實就是“紙老虎”。

濫用的典型案例是:在一個方法的內部,將入參資訊寫入 ThreadLocal 進行儲存,在後續需要時從 ThreadLocal 中取出使用。一段簡單的示例程式碼,可以參考:

public class TestService {

    private static final String COMMON = "1";

    private ThreadLocal<Map<String, Object>> commonThreadLocal = new ThreadLocal<>();

    public void testThreadLocal(String commonId, String activityId) {

        setCommonThreadLocal(commonId, activityId);

        // 省略業務程式碼①

        doSomething();

        // 省略業務程式碼②
    }

    /**
     * 將入參寫入 ThreadLocal
     *
     * @param commonId
     * @param activityId
     */
    private void setCommonThreadLocal(String commonId, String activityId) {
        Map<String, Object> params = new HashMap<>();
        params.put("commonId", commonId);
        params.put("activityId", activityId);
        this.commonThreadLocal.set(params);
    }

    /**
     * 從 ThreadLocal 取出引數,進行業務處理
     */
    private void doSomething() {
        Map<String, Object> params = this.commonThreadLocal.get();
        String commonId = (String) params.get("commonId");
        if (StringUtils.equals(commonId, COMMON)) {
            // 省略業務程式碼
        }
    }
}


為什麼說無傷大雅呢?因為這段程式碼的寫入 ThreadLocal 和讀取 ThreadLocal 都是在同一個執行緒中進行的,程式碼可以正常執行,並且執行結果正確。

但是,還是這段程式碼,也埋了一個“坑”,稍有不慎,將可能導致錯誤的結果。如果在處理業務邏輯中(①或者②處)使用了多執行緒技術,建立了其他執行緒,在其他執行緒中去獲取ThreadLocal中寫入的值,根據獲取到的值進行相關業務邏輯處理,很可能得到預期之外的結果,從而演化為一個錯誤案例

錯用:血淚教訓

錯誤案例

以一個常見的 Web 應用為例,方便起見,我在本機 Idea 使用 Spring Boot 建立一個工程,在 Controller 中使用 ThreadLocal 來儲存執行緒中的使用者資訊,初識為 null。業務邏輯很簡單,先從 ThreadLocal 獲取一次值,然後把入參中的 uid 設定到 ThreadLocal 中,隨後再獲取一次值,最後返回兩次獲得的 uid。程式碼如下:

private static final ThreadLocal<String> USER_INFO_THREAD_LOCAL = ThreadLocal.withInitial(() -> null);


@RequestMapping("user")
public String user(@RequestParam("uid") String uid) {
    //查詢 ThreadLocal 中的使用者資訊
    String before = USER_INFO_THREAD_LOCAL.get();
    //設定使用者資訊
    USER_INFO_THREAD_LOCAL.set(uid);
    //再查詢一次 ThreadLocal 中的使用者資訊
    String after = USER_INFO_THREAD_LOCAL.get();

    return before + ";" + after;
}


啟動工程,使用 uid=1,uid=2 ……作為入參進行測試,結果如下:

http://localhost:8080/user?uid=1 :沒有問題!

竟然有90%的ThreadLocal都在濫用或錯用!

http://localhost:8080/user?uid=2 :很穩!

竟然有90%的ThreadLocal都在濫用或錯用!

多來幾次,結果還是很穩的。

結果符合預期,這真的沒有問題嗎?

問到這裏,你是不是也有點懷疑了?是不是我要翻車了?寫到這裏就被迫結束了。NO!NO!NO!繼續看!

我調整 application.properties 引數,方便復現問題:

server.tomcat.max-threads=1


繼續執行上面的測試:

http://localhost:8080/user?uid=1 :沒有問題!

竟然有90%的ThreadLocal都在濫用或錯用!

http://localhost:8080/user?uid=2 :什麼?uid2 讀取到了 uid1 的資訊!!!

竟然有90%的ThreadLocal都在濫用或錯用!

http://localhost:8080/user?uid=1 :什麼?uid1 也讀取到了 uid2 的資訊!!!

竟然有90%的ThreadLocal都在濫用或錯用!

這豈不是亂套了,全亂了!

問題原因

為什麼資料會錯亂呢?

資料錯亂,究竟是怎麼回事呢?按理說,在設定使用者資訊之前第一次獲取的值始終應該是 null,然後設定之後再去讀取,讀到的應該是設定之後的值纔對啊。

真相是這樣的,程式執行在 Tomcat 中,Tomcat 的工作執行緒是基於執行緒池的,執行緒池其實是複用了一些固定的執行緒的

如果執行緒被複用,那麼很可能從 ThreadLocal 獲取的值是之前其他使用者的遺留下的值

為什麼調整執行緒池引數,就測試出問題了呢?

Spring Boot 內嵌的 Tomcat 伺服器的預設執行緒池最大執行緒數是 200,但透過修改 application.properties 或 application.yml 檔案來調整。關鍵引數如下:

  • 最大工作執行緒數 (server.tomcat.max-threads):預設值為 200,Tomcat 可以同時處理的最大執行緒數。

  • 最小工作執行緒數 (server.tomcat.min-spare-threads):預設值為 10,Tomcat 在啟動時初始化的執行緒數。

  • 最大連線數 (server.tomcat.max-connections):預設值為 10000,Tomcat 在任何時候可以接受的最大連線數。

  • 等待佇列長度 (server.tomcat.accept-count):預設值為 100,當所有執行緒都在使用時,等待佇列的最大長度。

我調整引數(server.tomcat.max-threads=1)之後,很容易複用到之前的執行緒,複用執行緒情況下,觸發了程式碼中隱藏的 Bug

如果不調整的話,在較大流量的場景下也會觸發這個 Bug

解決辦法

那應該如何修改呢?其實方案很簡單,在 finally 程式碼塊中顯式清除 ThreadLocal 中的資料。這樣,即使複用了之前的執行緒,也不會獲取到錯誤的使用者資訊。修正後的程式碼如下:

private static final ThreadLocal<String> USER_INFO_THREAD_LOCAL = ThreadLocal.withInitial(() -> null);

@RequestMapping("right")
public String right(@RequestParam("uid") String uid) {
    String before = USER_INFO_THREAD_LOCAL.get();
    USER_INFO_THREAD_LOCAL.set(uid);
    try {
        String after = USER_INFO_THREAD_LOCAL.get();
        return before + ";" + after;
    } finally {
        USER_INFO_THREAD_LOCAL.remove();
    }
}

正確使用

前面是濫用和錯用的例子,那應該如何正確使用 ThreadLocal 呢? 正確的使用場景包括:

  1. 在閘道器場景下,使用 ThreadLocal 來儲存追蹤請求的 ID、請求來源等資訊;

  2. RPC 等框架中使用 ThreadLocal 儲存請求上下文資訊;

  3. ……

最常見的案例是使用者登入攔截,從 HttpServletRequest 獲取到使用者資訊,並儲存到 ThreadLocal 中,方便後續隨時取用,程式碼如下:

public class ContextHttpInterceptor implements HandlerInterceptor {

    private static final ThreadLocal<Context> contextThreadLocal = new ThreadLocal<Context>();

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object o) throws Exception {
        try {
            Context context = new Context();
            String pin = request.getParameter("pin");
            if (StringUtils.isNotBlank(pin)) {
                context.setPin(pin);
            }
            contextThreadLocal.set(context);
        } catch (Exception e) {
        }
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse resposne, Object o,
                           ModelAndView modelAndView) throws Exception {
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse resposne,
                                Object o, Exception e) throws Exception {
        contextThreadLocal.remove();
    }
}


public class Context {
    private String pin;

    public String getPin() {
        return pin;
    }

    public void setPin(String pin) {
        this.pin = pin;
    }
}

總結

本文給大家介紹了 ThreadLocal 的無傷大雅的濫用案例、血淚教訓的錯誤案例,分析問題原因和解決方法,也給出了正確的案例,希望對大家理解和使用 ThreadLocal 有幫助。

真正的高手往往使用最樸實無華的招數,寫出無可挑剔的程式碼;有時候炫技式的程式碼可能會出錯。

大師級程式設計師把系統當作故事來講,而不是當作程式來寫。把故事講好,即方便自己閱讀,也方便別人閱讀,共勉。

0則評論

您的電子郵件等資訊不會被公開,以下所有項目均必填

OK! You can skip this field.