這篇文章主要介紹了Spring中使用自定義ThreadLocal存儲導致的坑怎么解決的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Spring中使用自定義ThreadLocal存儲導致的坑怎么解決文章都會有所收獲，下面我們一起來看看吧。

前進ssl適用于網站、小程序/APP、API接口等需要進行數據傳輸應用場景，ssl證書未來市場廣闊！成為成都創新互聯的ssl證書銷售渠道，可以享受市場價格4-6折優惠！如果有意向歡迎電話聯系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

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（）;

// &hellip;

}

}

這個方法也是很多博客中使用的。然而這個方法卻存在著一個很隱蔽的坑： HandlerInterceptor 的 postHandle 并不總是會調用。

當 Controller 中出現 Exception：

@Slf4j

@RestController

class Controller {

public Result get（） {

long userId = SecurityContextHolder.get（）。getUserId（）;

// &hellip;

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）;

}

// &hellip;

throw new RuntimeException（）;

//&hellip;

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 應該額外小心。

關于“Spring中使用自定義ThreadLocal存儲導致的坑怎么解決”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Spring中使用自定義ThreadLocal存儲導致的坑怎么解決”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注創新互聯行業資訊頻道。

網頁題目：Spring中使用自定義ThreadLocal存儲導致的坑怎么解決
瀏覽路徑：http://vcdvsql.cn/article10/pephdo.html

成都網站建設公司_創新互聯，為您提供小程序開發、定制開發、網站收錄、網站改版、微信小程序、App設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯