Spring中使用自定義ThreadLocal存儲導致的坑及解決方法是什么

本篇文章為大家展示了Spring中使用自定義ThreadLocal存儲導致的坑及解決方法是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Spring自定義ThreadLocal存儲導致的坑

Spring 中有時候我們需要存儲一些和 Request 相關聯(lián)的變量，例如用戶的登陸有關信息等，它的生命周期和 Request 相同。

一個容易想到的實現(xiàn)辦法是使用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中出現(xiàn)Exception

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

或者在HandlerInterceptor的preHandle中出現(xiàn)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 環(huán)境中，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 相當于線程內(nèi)部的 static 變量，是一個非常容易產(chǎn)生泄露的點，因此使用 ThreadLocal 應該額外小心。

Threadlocal可能會產(chǎn)生內(nèi)存泄露的問題及原理

剛遇到一個關于threadlocal的內(nèi)存泄漏問題，剛好總結一下

比較常用的這里先不提，直接提比較重要的部分

為什么會產(chǎn)生內(nèi)存泄露？

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對象由于被內(nèi)部ThreadLocalMap 引用，不會GC，可能會導致內(nèi)存泄露。

JVM解決的辦法

static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;
            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

繼承了一個軟引用，在系統(tǒng)進行gc的時候就可以回收

但是回收以后，key變成null，value也無法被訪問到，還是可能存在內(nèi)存泄露。 因此一旦不用了，必須對里面的keyvalue對remove掉，否則就會有內(nèi)存泄露；而且在threadlocal源碼里面，在每次get或者set的時候會清楚里面key為value的記錄

上述內(nèi)容就是Spring中使用自定義ThreadLocal存儲導致的坑及解決方法是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。