分享更有价值
被信任是一种快乐

Spring中使用自定义ThreadLocal存储导致的坑怎么解决

文章页正文上

这篇文章主要介绍了Spring中使用自定义ThreadLocal存储导致的坑怎么解决的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇Spring中使用自定义ThreadLocal存储导致的坑怎么解决文章都会有所收获,下面我们一起来看看吧。
  Spring 中有时候我们需要存储一些和 Request 相关联的变量,例如用户的登陆有关信息等,它的生命周期和 Request 相同。一个容易想到的实现办法是使用 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();
  }
  }
  使用一个自定义的 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 应该额外小心。关于“Spring中使用自定义ThreadLocal存储导致的坑怎么解决”这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对“Spring中使用自定义ThreadLocal存储导致的坑怎么解决”知识都有一定的了解,大家如果还想学习更多知识,欢迎关注云技术行业资讯频道。

相关推荐: jQuery.getJSON有什么用

小编给大家分享一下jQuery.getJSON有什么用,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!   jQuery.getJSON( url [, data ] [, success(data, textStatus, jqXHR) ] …

文章页内容下
赞(0) 打赏
版权声明:本站采用知识共享、学习交流,不允许用于商业用途;文章由发布者自行承担一切责任,与本站无关。
文章页正文下
文章页评论上

云服务器、web空间可免费试用

宝塔面板主机、支持php,mysql等,SSL部署;安全高速企业专供99.999%稳定,另有高防主机、不限制内容等类型,具体可咨询QQ:360163164,Tel同微信:18905205712

主机选购导航云服务器试用

登录

找回密码

注册