Spring Bean的线程安全问题

目录
  • @Controller、@Service是不是线程安全的?
  • ThreadLocal vs 线程同步机制
    • 线程同步机制
    • ThreadLocal
  • 总结

Spring容器中的Bean是否线程安全,容器本身并没有提供Bean的线程安全策略,因此可以说Spring容器中的Bean本身不具备线程安全的特性,但是具体还是要结合具体scope的Bean去研究。

Spring的bean作用域(scope)类型:

  • singleton
  • prototype
  • request
  • session
  • global-session

线程安全这个问题,要从单例与原型Bean分别进行说明:

  • 原型Bean:对于原型Bean,每次创建一个新对象,也就是线程之间并不存在Bean共享,自然是不会有线程安全的问题
  • 单例Bean:对于单例Bean,所有线程都共享一个单例实例Bean,因此是存在资源的竞争。如果单例Bean是一个无状态Bean,也就是线程中的操作不会对Bean的成员执行 查询 以外的操作,那么这个单例Bean是线程安全的。比如Spring mvc的 Controller 、 Service 、 Dao 等,这些Bean大多是无状态的,只关注于方法本身

bean 分为 有状态 bean 和无状态 bean ,有状态 bean 即类定义了成员变量,可能被多个线程同时访问,则会出现线程安全问题;无状态 bean 每个线程访问不会产生线程安全问题,因为各个线程栈及方法栈资源都是独立的,不共享。即是,无状态 bean 可以在多线程环境下共享,有状态 bean不能

Spring中的Bean默认是单例模式的,框架并没有对bean进行多线程的封装处理。

实际上大部分时间Bean是无状态的(比如Dao) 所以说在某种程度上来说Bean其实是安全的。

但是如果Bean是有状态的,那就需要开发人员自己来进行线程安全的保证,最简单的办法就是改变bean的作用域,把 singleton 改为 protopyte 这样每次请求Bean就相当于是 new Bean() 这样就可以保证线程的安全了。

  • 有状态就是有数据存储功能
  • 无状态就是不会保存数据

Controller 、 Service 和 Dao 层本身并不是线程安全的,只是如果只是调用里面的方法,而且多线程调用一个实例的方法,会在内存中复制变量,这是自己的线程的工作内存,是安全的。

Java虚拟机栈是线程私有的,它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型:每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

局部变量的固有属性之一就是封闭在执行线程中。 它们位于执行线程的栈中,其他线程无法访问这个栈。

所以其实任何无状态单例都是线程安全的。

Spring的根本就是通过大量这种单例构建起系统,以事务脚本的方式提供服务。

@Controller、@Service是不是线程安全的?

默认配置下不是的。 因为默认情况下@Controller没有加上@Scope,没有加@Scope就是默认值singleton,单例的 。意思就是系统只会初始化一次 Controller 容器,所以每次请求的都是同一个 Controller 容器,当然是非线程安全的。举个栗子:

@RestController
public class TestController {
    private int var = 0;
    @GetMapping(value = "/test_var")
    public String test() {
        System.out.println("普通变量var:" + (++var));
        return "普通变量var:" + var ;
    }
}

在postman里面发三次请求,结果如下:

普通变量var:1
普通变量var:2
普通变量var:3

说明它不是线程安全的。可以给它加上 @Scope 注解,如下:

@RestController
@Scope(value = "prototype") // 加上@Scope注解,有2个取值:单例-singleton 多实例-prototype
public class TestController {
    private int var = 0;
    @GetMapping(value = "/test_var")
    public String test() {
        System.out.println("普通变量var:" + (++var));
        return "普通变量var:" + var ;
    }
}

这样一来,每个请求都单独创建一个 Controller 容器,所以各个请求之间是线程安全的,三次请求结果:

普通变量var:1
普通变量var:1
普通变量var:1

加了 @Scope 注解的 prototype 实例一定就是线程安全的吗?

@RestController
@Scope(value = "prototype") // 加上@Scope注解,有2个取值:单例-singleton 多实例-prototype
public class TestController {
    private int var = 0;
    private static int staticVar = 0;
​
    @GetMapping(value = "/test_var")
    public String test() {
        System.out.println("普通变量var:" + (++var)+ "---静态变量staticVar:" + (++staticVar));
        return "普通变量var:" + var + "静态变量staticVar:" + staticVar;
    }
}

三次请求结果:

普通变量var:1---静态变量staticVar:1
普通变量var:1---静态变量staticVar:2
普通变量var:1---静态变量staticVar:3

虽然每次都是单独创建一个 Controller 但是扛不住它变量本身是 static 的,所以说,即便是加上 @Scope 注解也不一定能保证 Controller 100%的线程安全。所以是否线程安全在于怎样去定义变量以及 Controller 的配置。来个全乎一点的实验,代码如下:

@RestController
@Scope(value = "singleton") // prototype singleton
public class TestController {
​
    private int var = 0; // 定义一个普通变量
​
    private static int staticVar = 0; // 定义一个静态变量
​
    @Value("${test-int}")
    private int testInt; // 从配置文件中读取变量
​
    ThreadLocal<Integer> tl = new ThreadLocal<>(); // 用ThreadLocal来封装变量
​
    @Autowired
    private User user; // 注入一个对象来封装变量
​
    @GetMapping(value = "/test_var")
    public String test() {
        tl.set(1);
        System.out.println("先取一下user对象中的值:"+user.getAge()+"===再取一下hashCode:"+user.hashCode());
        user.setAge(1);
        System.out.println("普通变量var:" + (++var) + "===静态变量staticVar:" + (++staticVar) + "===配置变量testInt:" + (++testInt)
                + "===ThreadLocal变量tl:" + tl.get()+"===注入变量user:" + user.getAge());
        return "普通变量var:" + var + ",静态变量staticVar:" + staticVar + ",配置读取变量testInt:" + testInt + ",ThreadLocal变量tl:"
                + tl.get() + "注入变量user:" + user.getAge();
    }
}@RestController
@Scope(value = "prototype") // prototype singleton
public class TestController {
​
    private int var = 0; // 定义一个普通变量
​
    private static int staticVar = 0; // 定义一个静态变量
​
    @Value("${test-int}")
    private int testInt; // 从配置文件中读取变量
​
    ThreadLocal<Integer> tl = new ThreadLocal<>(); // 用ThreadLocal来封装变量
​
    @Autowired
    private User user; // 注入一个对象来封装变量
​
    @GetMapping(value = "/test_var")
    public String test() {
        tl.set(1);
        System.out.println("先取一下user对象中的值:"+user.getAge()+"===再取一下hashCode:"+user.hashCode());
        user.setAge(1);
        System.out.println("普通变量var:" + (++var) + "===静态变量staticVar:" + (++staticVar) + "===配置变量testInt:" + (++testInt)
                + "===ThreadLocal变量tl:" + tl.get()+"===注入变量user:" + user.getAge());
        return "普通变量var:" + var + ",静态变量staticVar:" + staticVar + ",配置读取变量testInt:" + testInt + ",ThreadLocal变量tl:"
                + tl.get() + "注入变量user:" + user.getAge();
    }
}

补充 Controller 以外的代码:

config里面自己定义的Bean: User

@Configuration
public class MyConfig {
    @Bean
    public User user(){
        return new User();
    }
}

三次http请求结果如下:

先取一下user对象中的值:0===再取一下hashCode:241165852
普通变量var:1===静态变量staticVar:1===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:1===再取一下hashCode:241165852
普通变量var:2===静态变量staticVar:2===配置变量testInt:2===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:1===再取一下hashCode:241165852
普通变量var:3===静态变量staticVar:3===配置变量testInt:3===ThreadLocal变量tl:1===注入变量user:1

可以看到,在单例模式下 Controller 中只有用 ThreadLocal 封装的变量是线程安全的。可以看到3次请求结果里面只有 ThreadLocal 变量值每次都是从 0+1=1 的,其他的几个都是累加的,而 user 对象呢,默认值是0,第二交取值的时候就已经是1了,关键它的 hashCode 是一样的,说明每次请求调用的都是同一个 user 对象。

下面将 TestController 上的 @Scope 注解的属性改一下改成多实例的: @Scope(value = "prototype") ,其他都不变,再次请求,结果如下:

先取一下user对象中的值:0===再取一下hashCode:853315860
普通变量var:1===静态变量staticVar:1===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:1===再取一下hashCode:853315860
普通变量var:1===静态变量staticVar:2===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:1===再取一下hashCode:853315860
普通变量var:1===静态变量staticVar:3===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1

分析这个结果发现,多实例模式下普通变量,取配置的变量还有 ThreadLocal 变量都是线程安全的,而静态变量和 user (看它的 hashCode 都是一样的)对象中的变量都是非线程安全的。也就是说尽管 TestController 是每次请求的时候都初始化了一个对象,但是静态变量始终是只有一份的,而且这个注入的 user 对象也是只有一份的。静态变量只有一份这是当然的咯,那么有没有办法让 user 对象可以每次都new一个新的呢?当然可以:

public class MyConfig {
    @Bean
    @Scope(value = "prototype")
    public User user(){
        return new User();
    }
}

在config里面给这个注入的Bean加上一个相同的注解 @Scope(value = "prototype") 就可以了,再来请求一下:

先取一下user对象中的值:0===再取一下hashCode:1612967699
普通变量var:1===静态变量staticVar:1===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:0===再取一下hashCode:985418837
普通变量var:1===静态变量staticVar:2===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1
先取一下user对象中的值:0===再取一下hashCode:1958952789
普通变量var:1===静态变量staticVar:3===配置变量testInt:1===ThreadLocal变量tl:1===注入变量user:1

可以看到每次请求的 user 对象的 hashCode 都不是一样的,每次赋值前取 user 中的变量值也都是默认值0。

ThreadLocal vs 线程同步机制

ThreadLocal 和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

线程同步机制

在同步机制中,通过对象的 锁机制 保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的,使用同步机制要求程序慎密地分析什么时候对变量进行读写,什么时候需要锁定某个对象,什么时候释放对象锁等繁杂的问题,程序设计和编写难度相对较大。

ThreadLocal

  • ThreadLocal 则从另一个角度来解决多线程的并发访问。 ThreadLocal会为每一个线程提供一个独立的变量副本,从而隔离了多个线程对数据的访问冲突 。因为每一个线程都拥有自己的变量副本,从而也就没有必要对该变量进行同步了。 ThreadLocal 提供了线程安全的共享对象,在编写多线程代码时,可以把不安全的变量封装进 ThreadLocal 。
  • 由于 ThreadLocal 中可以持有任何类型的对象,低版本JDK所提供的 get() 返回的是 Object 对象,需要强制类型转换。但JDK 5.0通过泛型很好的解决了这个问题,在一定程度地简化 ThreadLocal 的使用

概括起来说,对于多线程资源共享的问题, 同步机制采用了“以时间换空间”的方式,而ThreadLocal采用了“以空间换时间”的方式 。前者仅提供一份变量,让不同的线程排队访问,而后者为每一个线程都提供了一份变量,因此可以同时访问而互不影响。

总结

  • 在 @Controller/@Service 等容器中,默认情况下,scope值是单例- singleton 的,也是线程不安全的
  • 尽量不要在 @Controller/@Service 等容器中定义静态变量,不论是单例( singleton )还是多实例( prototype )都是线程不安全的
  • 默认注入的Bean对象,在不设置scope的时候也是线程不安全的
  • 一定要定义变量的话,用 ThreadLocal 来封装,这个是线程安全的

到此这篇关于Spring Bean的线程安全问题的文章就介绍到这了,更多相关Spring Bean线程安全内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 浅谈Spring中单例Bean是线程安全的吗

    Spring容器中的Bean是否线程安全,容器本身并没有提供Bean的线程安全策略,因此可以说Spring容器中的Bean本身不具备线程安全的特性,但是具体还是要结合具体scope的Bean去研究. Spring 的 bean 作用域(scope)类型 1.singleton:单例,默认作用域. 2.prototype:原型,每次创建一个新对象. 3.request:请求,每次Http请求创建一个新对象,适用于WebApplicationContext环境下. 4.session:会话,同一个会

  • Spring Bean的线程安全问题

    目录 @Controller.@Service是不是线程安全的? ThreadLocal vs 线程同步机制 线程同步机制 ThreadLocal 总结 Spring容器中的Bean是否线程安全,容器本身并没有提供Bean的线程安全策略,因此可以说Spring容器中的Bean本身不具备线程安全的特性,但是具体还是要结合具体scope的Bean去研究. Spring的bean作用域(scope)类型: singleton prototype request session global-sessi

  • 解析Spring中@Controller@Service等线程安全问题

    目录 首先问@Controller@Service是不是线程安全的? 总结: 首先问@Controller @Service是不是线程安全的? 答:默认配置下不是的.为啥呢?因为默认情况下@Controller没有加上@Scope,没有加@Scope就是默认值singleton,单例的.意思就是系统只会初始化一次Controller容器,所以每次请求的都是同一个Controller容器,当然是非线程安全的.举个栗子: @RestController public class TestContro

  • Struts中action线程安全问题解析

    [问题描述] 最近公司安排我面试Java的FreshMan,面试者一般是工作1年多点的新人(这里我就装老一下,其实我也才工作3年不到),在被问及Struts1和Struts2的Action的线程安全问题的时候,大多是支支吾吾,答不出所以然.所以在这里我整理一下我个人的理解. [问题答案] 这是由于Servlet的工作原理产生的.我们先来简单回顾一下Servlet的生命周期"初始化->init->service->destroy->卸载". 这里大家都知道,我们在

  • Java 单例模式线程安全问题

    Java 单例模式线程安全问题 SpringIOC容器默认提供bean的访问作用域是单例模式.即在整个application生命周期中,只有一个instance.因此在多线程并发下,会有线程安全风险.我们在MVC框架下的servlet就是线程安全的.由于该servlet是在客户端,多并发相对少,但是对于web service端,需要考虑到. ThreadLocal类:为每一个线程提供了一个独立的变量(实例)副本,从各将各个不同的实例访问isolation. 在同步锁机制中,后来者线程等待先行线程

  • 使用springboot单例模式与线程安全问题踩的坑

    springboot单例模式与线程安全问题踩的坑 最近有客户反映,使用公司产品时,偶尔会存在崩溃情况,自己测试无问题,然后去查日志,是报空指针. 于是顺藤摸瓜 往上找,好嘛,之前的开发使用了成员变量,感觉问题就是在这里了,因为众所周知,springboot 采用的是单例模式,所以,使用成员变量时一定要谨慎. 下面上一张该类的截图: 大家可能看到了,该类上面加上了@Scope("prototype") 注解,该注解的作用是将该类变成多例模式.讲道理因为变为了多例,应该不会有线程问题了.

  • Spring Bean Scope 有状态的Bean与无状态的Bean

    有状态会话bean:每个用户有自己特有的一个实例,在用户的生存期内,bean保持了用户的信息,即“有状态”:一旦用户灭亡(调用结束或实例结束),bean的生命期也告结束.即每个用户最初都会得到一个初始的bean.         无状态会话bean:bean一旦实例化就被加进会话池中,各个用户都可以共用.即使用户已经消亡,bean   的生命期也不一定结束,它可能依然存在于会话池中,供其他用户调用.由于没有特定的用户,那么也就不能保持某一用户的状态,所以叫无状态bean.但无状态会话bean  

  • 一文搞懂Spring Bean中的作用域和生命周期

    目录 一.Spring Bean 作用域 singleton(单例) prototype(原型) 小结 二.Spring Bean生命周期 如何关闭容器 生命周期回调 通过接口设置生命周期 通过xml设置生命周期 一.Spring Bean 作用域 常规的 Spring IoC 容器中Bean的作用域有两种:singleton(单例)和prototype(非单例) 注:基于Web的容器还有其他种作用域,在这就不赘述了. singleton(单例) singleton是Spring默认的作用域.当

  • 基于Spring中的线程池和定时任务功能解析

    1.功能介绍 Spring框架提供了线程池和定时任务执行的抽象接口:TaskExecutor和TaskScheduler来支持异步执行任务和定时执行任务功能.同时使用框架自己定义的抽象接口来屏蔽掉底层JDK版本间以及Java EE中的线程池和定时任务处理的差异. 另外Spring还支持集成JDK内部的定时器Timer和Quartz Scheduler框架. 2.线程池的抽象:TaskExecutor TaskExecutor涉及到的相关类图如下: TaskExecutor接口源代码如下所示: p

  • 浅谈Spring @Async异步线程池用法总结

    本文介绍了Spring @Async异步线程池用法总结,分享给大家,希望对大家有帮助 1. TaskExecutor spring异步线程池的接口类,其实质是Java.util.concurrent.Executor Spring 已经实现的异常线程池: 1. SimpleAsyncTaskExecutor:不是真的线程池,这个类不重用线程,每次调用都会创建一个新的线程. 2. SyncTaskExecutor:这个类没有实现异步调用,只是一个同步操作.只适用于不需要多线程的地方 3. Conc

随机推荐