Spring 中使用自定義的 ThreadLocal 存儲致使的坑

 Spring 中有時候咱們須要存儲一些和 Request 相關聯的變量，例如用戶的登錄有關信息等，它的生命週期和 Request 相同。一個容易想到的實現辦法是使用 ThreadLocal：

public class SecurityContextHolder {
    private static final ThreadLocal<SecurityContext> securityContext = new ThreadLocal<SecurityContext>();
    public static void set(SecurityContext context) {
        securityContext.set(context);
    }
    public static SecurityContext get() {
        return securityContext.get();
    }
    public static void clear() {
        securityContext.remove();
    }
}
複製代碼

使用一個自定義的 HandlerInterceptor 將有關信息注入進去：

@Slf4j
@Component
public class RequestInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws
            Exception {
        try {
            SecurityContextHolder.set(retrieveRequestContext(request));
        } catch (Exception ex) {
            log.warn("讀取請求信息失敗", ex);
        }
        return true;
    }
    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable
            ModelAndView modelAndView) throws Exception {
        SecurityContextHolder.clear();
}
複製代碼

經過這樣，咱們就能夠在 Controller 中直接使用這個 context，很方便的獲取到有關用戶的信息：

@Slf4j
@RestController
class Controller {
  public Result get() {
     long userId = SecurityContextHolder.get().getUserId();
     // ...
  }
}
複製代碼

這個方法也是不少博客中使用的。然而這個方法卻存在着一個很隱蔽的坑： HandlerInterceptor 的 postHandle 並不老是會調用。

當 Controller 中出現 Exception：

@Slf4j
@RestController
class Controller {
  public Result get() {
     long userId = SecurityContextHolder.get().getUserId();
     // ...
     throw new RuntimeException();
  }
}
複製代碼

或者在 HandlerInterceptor 的 preHandle 中出現 Exception：

@Slf4j
@Component
public class RequestInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws
            Exception {
        try {
            SecurityContextHolder.set(retrieveRequestContext(request));
        } catch (Exception ex) {
            log.warn("讀取請求信息失敗", ex);
        }
        // ...
        throw new RuntimeException();
        //...
        return true;
    }
}
複製代碼

這些狀況下， postHandle 並不會調用。這就致使了 ThreadLocal 變量不能被清理。

在日常的 Java 環境中，ThreadLocal 變量隨着 Thread 自己的銷燬，是能夠被銷燬掉的。但 Spring 因爲採用了線程池的設計，響應請求的線程可能會一直常駐，這就致使了變量一直不能被 GC 回收。更糟糕的是，這個沒有被正確回收的變量，因爲線程池對線程的複用，可能會串到別的 Request 當中，進而直接致使代碼邏輯的錯誤。

爲了解決這個問題，咱們可使用 Spring 自帶的 RequestContextHolder ，它背後的原理也是 ThreadLocal，不過它總會被更底層的 Servlet 的 Filter 清理掉，所以不存在泄露的問題。

下面是一個使用 RequestContextHolder 重寫的例子：

public class SecurityContextHolder {
    private static final String SECURITY_CONTEXT_ATTRIBUTES = "SECURITY_CONTEXT";
    public static void setContext(SecurityContext context) {
        RequestContextHolder.currentRequestAttributes().setAttribute(
                SECURITY_CONTEXT_ATTRIBUTES,
                context,
                RequestAttributes.SCOPE_REQUEST);
    }
    public static SecurityContext get() {
        return (SecurityContext)RequestContextHolder.currentRequestAttributes()
                .getAttribute(SECURITY_CONTEXT_ATTRIBUTES, RequestAttributes.SCOPE_REQUEST);
    }
}
複製代碼

除了使用 RequestContextHolder 還可使用 Request Scope 的 Bean，或者使用 ThreadLocalTargetSource ，原理上是相似的。

須要時刻注意 ThreadLocal 至關於線程內部的 static 變量，是一個很是容易產生泄露的點，所以使用 ThreadLocal 應該額外當心。

歡迎工做一到五年的Java工程師朋友們加入Java程序員開發： 721575865

羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！