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

目录
  • Spring自定义ThreadLocal存储导致的坑
    • 一个容易想到的实现办法是使用ThreadLocal
  • Threadlocal可能会产生内存泄露的问题及原理
    • 为什么会产生内存泄露?
    • JVM解决的办法

Spring自定义ThreadLocal存储导致的坑

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();
     // ...
  }
}

这个方法也是很多博客中使用的。然而这个方法却存在着一个很隐蔽的坑: 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可能会产生内存泄露的问题及原理

刚遇到一个关于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,可能会导致内存泄露。

JVM解决的办法

        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的记录

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 详解Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失

    在Spring Cloud中我们用Hystrix来实现断路器,Zuul中默认是用信号量(Hystrix默认是线程)来进行隔离的,我们可以通过配置使用线程方式隔离. 在使用线程隔离的时候,有个问题是必须要解决的,那就是在某些业务场景下通过ThreadLocal来在线程里传递数据,用信号量是没问题的,从请求进来,但后续的流程都是通一个线程. 当隔离模式为线程时,Hystrix会将请求放入Hystrix的线程池中去执行,这个时候某个请求就有A线程变成B线程了,ThreadLocal必然消失了. 下面我

  • 彻底理解Java中的ThreadLocal

    ThreadLocal翻译成中文比较准确的叫法应该是:线程局部变量.  ThreadLocal是什么 早在JDK 1.2的版本中就提供Java.lang.ThreadLocal,ThreadLocal为解决多线程程序的并发问题提供了一种新的思路.使用这个工具类可以很简洁地编写出优美的多线程程序. 当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本. 从线程的角度看,目标变

  • 彻底理解Java 中的ThreadLocal

     ThreadLocal是什么 早在JDK 1.2的版本中就提供Java.lang.ThreadLocal,ThreadLocal为解决多线程程序的并发问题提供了一种新的思路.使用这个工具类可以很简洁地编写出优美的多线程程序. 当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本. 从线程的角度看,目标变量就象是线程的本地变量,这也是类名中"Local"所要表达的

  • java 中ThreadLocal本地线程和同步机制的比较

    ThreadLocal的设计 首先看看ThreadLocal的接口: Object get() ; // 返回当前线程的线程局部变量副本 protected Object initialValue(); // 返回该线程局部变量的当前线程的初始值 void set(Object value); // 设置当前线程的线程局部变量副本的值 ThreadLocal有3个方法,其中值得注意的是initialValue(),该方法是一个protected的方法,显然是为了子类重写而特意实现的.该方法返回当

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

    目录 Spring自定义ThreadLocal存储导致的坑 一个容易想到的实现办法是使用ThreadLocal Threadlocal可能会产生内存泄露的问题及原理 为什么会产生内存泄露? JVM解决的办法 Spring自定义ThreadLocal存储导致的坑 Spring 中有时候我们需要存储一些和 Request 相关联的变量,例如用户的登陆有关信息等,它的生命周期和 Request 相同. 一个容易想到的实现办法是使用ThreadLocal public class SecurityCon

  • Spring中@RequestParam使用及遇到的一些坑

    目录 加与不加的区别 使用RequestParam遇到的一些坑(总结) 总结 加与不加的区别 @RequestMapping("/list1") public String test1(int userId) { return "list"; } @RequestMapping("/list2") public String test2(@RequestParam int userId) { return "list"; }

  • MySQL5.7中的sql_mode默认值带来的坑及解决方法

    在正常项目开发过程中,如果MySQL版本从5.6升级到5.7版本.作为DBA在考虑数据库版本升级带来的影响时,一般会有几个注意点: sql_mode optimizer_switch 本文主要内容是MySQL升级到5.7版本之后,由于默认的 sql_mode 值带来的坑以及对应的解决方案. 案例一:ONLY_FULL_GROUP_BY 问题描述 MySQL版本从5.6升级至5.7之后,部分SQL执行报错,报错信息如下: ERROR 1055 (42000): Expression #3 of X

  • 在spring中使用自定义注解注册监听器的方法

    接口回调 监听器本质上就是利用回调机制,在某个动作发生前或后,执行我们自己的一些代码.在Java语言中,可以使用接口来实现. 实现一个监听器案例 为了方便,直接在spring环境中定义:以工作(work)为例,定义工作开始时(或结束时)的监听器. 1. 定义回调的接口 package com.yawn.demo.listener; /** * @author Created by yawn on 2018-01-21 13:53 */ public interface WorkListener

  • spring中bean id相同引发故障的分析与解决

    前言 最近因为同事bean配置的问题导致生产环境往错误的redis实例写入大量的数据,差点搞挂redis.经过快速的问题定位,发现是同事新增一个redis配置文件,并且配置的RedisSentinelConfiguration的id是一样的,然后在使用@Autowired注入bean的时候因为spring bean覆盖的机制导致读取的redis配置不是原来的. 总结起来,有两点问题: 为什么相同bean id的bean会被覆盖 @Autowired注解不是按照byType的方式进行注入的吗 代码

  • JAVA Spring中让人头痛的JAVA大事务问题要如何解决你知道吗

    目录 前言 大事务引发的问题 解决办法 少用@Transactional注解 将查询(select)方法放到事务外 事务中避免远程调用 事务中避免一次性处理太多数据 非事务执行 总结 前言 最近有个网友问了我一个问题:系统中大事务问题要如何处理? 正好前段时间我在公司处理过这个问题,我们当时由于项目初期时间比较紧张,为了快速完成业务功能,忽略了系统部分性能问题.项目顺利上线后,专门抽了一个迭代的时间去解决大事务问题,目前已经优化完成,并且顺利上线.现给大家总结了一下,我们当时使用的一些解决办法,

  • spring中使用@Autowired注解无法注入的情况及解决

    目录 spring @Autowired注解无法注入 问题简述 原因:(此处只说第二种) 解决方案 @Autowired注解注入失败,提示could not autowire spring @Autowired注解无法注入 问题简述 在使用spring框架的过程中,常会遇到这种两情况: 1.在扫描的包以外使用需要使用mapper 2.同目录下两个controller或者两个service,在使用@Autowired注解注入mapper或者service时,其中一个可以注入,另一个却为空. 原因:

  • Vue中使用axios调用后端接口的坑及解决

    目录 axios调用后端接口的坑 问题场景 总结了如下场景 调用后端接口 使用axios跨域问题 首先找到项目中vue.config.js axios调用后端接口的坑 问题场景 Vue.js工程中使用axios调用后端接口(SpringBoot构建)出现后端接口无法获得数据的情况 总结了如下场景 @RequestParam用来处理application/x-www-form-urlencoded编码(HTTP协议请求头中不指定Content-Type默认就是application/x-www-f

  • spring boot RestTemplate 发送get请求的踩坑及解决

    spring boot RestTemplate 发送get请求踩坑 闲话少说,代码说话 RestTemplate 实例 手动实例化,这个我基本不用 RestTemplate restTemplate = new RestTemplate(); 依赖注入,通常情况下我使用 java.net 包下的类构建的 SimpleClientHttpRequestFactory @Configuration public class RestConfiguration { @Bean @Conditiona

  • CentOS 7中升级MySQL 5.7.23的坑与解决方法

    前言 最近发现CentOS 7下升级MySQL5.7.23的一个坑,以前面升级到MySQL 5.7.23的一个集群为例 在我们环境下打开文件描述符个数的参数open_files_limit在MySQL 5.6.21下都统一配置为65535,而CentOS 7系统下安装MySQL5.7.23的open_files_limit参数的默认值为5000 否则像分区表数量较多的集群,打开的文件个数过大时,数据库就会报错. 原因如下: 1.CentOS 7安装MySQL5.7.23,服务管理发生了变化,从s

随机推荐