Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of how to solve the pit caused by the use of custom ThreadLocal storage in Spring, the content is detailed and easy to understand, the operation is simple and quick, and has a certain reference value. I believe you will gain something after reading this article on how to solve the pit caused by the use of custom ThreadLocal storage in Spring. Let's take a look.

In Spring, sometimes we need to store some variables associated with Request, such as user login information, and its life cycle is the same as Request. An easy-to-think implementation is to use ThreadLocal:

Public class SecurityContextHolder {

Private static final ThreadLocal securityContext = new ThreadLocal ()

Public static void set (SecurityContext context) {

SecurityContext.set (context)

}

Public static SecurityContext get () {

Return securityContext.get ()

}

Public static void clear () {

SecurityContext.remove ()

}

}

Use a custom HandlerInterceptor to inject relevant information:

@ 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 ("failed to read request information", ex)

}

Return true

}

@ Override

Public void postHandle (HttpServletRequest request, HttpServletResponse response, Object handler, @ Nullable)

ModelAndView modelAndView) throws Exception {

SecurityContextHolder.clear ()

}

In this way, we can use the context directly in Controller and get information about the user easily:

@ Slf4j

@ RestController

Class Controller {

Public Result get () {

Long userId = SecurityContextHolder.get (). GetUserId ()

/ / …

}

}

This method is also used in many blogs. However, there is a hidden hole in this method: HandlerInterceptor's postHandle is not always called.

When Exception appears in Controller:

@ Slf4j

@ RestController

Class Controller {

Public Result get () {

Long userId = SecurityContextHolder.get (). GetUserId ()

/ / …

Throw new RuntimeException ()

}

}

Or Exception appears in the preHandle of 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 ("failed to read request information", ex)

}

/ / …

Throw new RuntimeException ()

/ / …

Return true

}

}

In these cases, postHandle is not called. This causes the ThreadLocal variable not to be cleaned up.

In a normal Java environment, the ThreadLocal variable can be destroyed with the destruction of the Thread itself. However, due to the thread pool design of Spring, the thread responding to the request may be resident all the time, which results in that the variable cannot be reclaimed by GC all the time. To make matters worse, this variable that has not been properly recycled may be strung into another Request due to the reuse of threads by the thread pool, which directly leads to code logic errors.

To solve this problem, we can use the RequestContextHolder that comes with Spring, which is also based on ThreadLocal, but it is always cleaned up by the lower-level Servlet Filter, so there is no leakage problem.

Here is an example of using RequestContextHolder rewriting:

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)

}

}

In addition to using RequestContextHolder, you can also use Request Scope's Bean, or ThreadLocalTargetSource, which is similar in principle.

It is important to keep in mind that ThreadLocal is the equivalent of a static variable within a thread and is a very easy point to leak, so you should be extra careful when using ThreadLocal.

This is the end of the article on "how to solve the pits caused by the use of custom ThreadLocal storage in Spring". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "how to solve the pit caused by the use of custom ThreadLocal storage in Spring". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.