您好,登錄后才能下訂單哦!
本篇文章為大家展示了Spring中使用自定義ThreadLocal存儲導致的坑及解決方法是什么,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
Spring 中有時候我們需要存儲一些和 Request 相關聯的變量,例如用戶的登陸有關信息等,它的生命周期和 Request 相同。
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 應該額外小心。
剛遇到一個關于threadlocal的內存泄漏問題,剛好總結一下
比較常用的這里先不提,直接提比較重要的部分
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); }
set方法里面,先調用到當前線程thread,每個線程里都會有一個threadlocals成員變量,指向對應的ThreadLocalMap ,然后以new出來的引用作為key,和給定的value一塊保存起來。
當外部引用解除以后,對應的ThreadLocal對象由于被內部ThreadLocalMap 引用,不會GC,可能會導致內存泄露。
static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }
繼承了一個軟引用,在系統進行gc的時候就可以回收
但是回收以后,key變成null,value也無法被訪問到,還是可能存在內存泄露。 因此一旦不用了,必須對里面的keyvalue對remove掉,否則就會有內存泄露;而且在threadlocal源碼里面,在每次get或者set的時候會清楚里面key為value的記錄
上述內容就是Spring中使用自定義ThreadLocal存儲導致的坑及解決方法是什么,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。