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线程安全内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax!

Spring Bean的线程安全问题的更多相关文章

  1. ios – Realm Swift模型是否分开?

    我是iOS和Swift的世界的新手,正在开发一个新的应用程序,我想使用领域来保持持久性.我的代码中已经有我的服务访问和填充HTTPAPI端点的实体.现在我想坚持一些实体,并且想要建议我是否应该为每个实体创建新的领域特定的模型,以便从领域读写.或者我应该将我现有的所有简单的Swift实体转换为国家实体.起初,我感觉到错误,因为我将在我的应用程序中传递RealmEntities,而不是在持久层中.但是

  2. 在Swift中应用Grand Central Dispatch(上

    在这两篇教程中,你会学到GCD的来龙去脉。起步libdispatch是Apple所提供的在IOS和OSX上进行并发编程的库,而GCD正是它市场化的名字。Swift中的闭包和OC中的块类似甚至于他们几乎就是可交换使用的。但OC中的块可以安全的替换成Swift中的闭包。再一次,这完全取决于GCD。QoS等级表示了提交任务的意图,使得GCD可以决定如何制定优先级。QOS_CLASS_USER_INteraCTIVE:userinteractive等级表示任务需要被立即执行以提供好的用户体验。

  3. 【荐】Grand Central Dispatch Tutorial for Swift: Part 1/2

    所有的dispatchqueues自身都是线程安全的。dispatch_sync把任务添加到对应队列并等待其完成后再继续执行当前任务,容易造成死锁,或阻塞当前任务。dispatch_after指定时间后把任务添加到队列中。效果就像是延时后的dispatch_async。而array和dictionary在swift中是以struct的形式实现的,所以以上的读操作返回的是一个副本。在GCD中使用dispatchbarrier来解决这个问题。dispatchbarrier是一组方法,它们都已顺序化的方式来结合

  4. swift详解之十六-----------GCD基础部分

    当你了解了调度队列如何为你自己代码的不同部分提供线程安全后,GCD的优点就是显而易见的。这完全取决于GCD。这个队列就是用于发生消息给UIView或发送通知的。GCD的“艺术”归结为选择合适的队列来调度函数以提交你的工作。

  5. Swift多种实现单例写法

    学习Swift的单例写法,以下提供了5种方式,一起来看看吧!

  6. Swift线程安全详解-概念,三种锁,死锁,Atomic,synchronized

    研究了下,是线程安全问题。UIKit以及Fundation事实上,大多数Cocoa提供的Api都不是线程安全的,尤其是与UI相关的UIKit,只能在主线程上操作。需要线程安全的时候,开发者自己维护就可以了。用来加锁,解锁。关于ObjectiveC参考这篇文章Atomic一个非Atomic的属性在非ARC的时候像这样可以看到,如果在多线程同时set的情况下,可能会造成release两次。Property的Runtime对应的C代码为可以看到,如果是nonatomic的,synchronized可以看看这个S

  7. swift - singleton

    关于单例,有三个重要的准则需要牢记:单例必须是唯一的,在程序生命周期中只能存在一个这样的实例。单例的存在使我们可以全局访问状态。为保证单例的唯一性,单例类的初始化方法必须是私有的。这样就可以避免其他对象通过单例类创建额外的实例。通过调用dispatch_once,即可保证实例化代码只运行一次。

  8. Swift线程安全的单例实现

    介绍单例模式在开发中尤为常见,最大的好处就是内存中只会保留一个对象,节省内存开销,同时便于对象的建立和维护。一个简单的单例这个单例,如此的简单那么他是线程安全的吗?答案是—————是!原因很简单,let定义的属性本身就是threadsafe的,同时static定义的是一个classconstant,拥有全局作用域和懒加载特性。如果你是Swift1.2以下的你可以这么写用GCD来实现线程安全这个实现大家应该相当熟悉,这里就不再过多介绍了。

  9. Swift 线程安全数组

    有并发的地方就存在线程安全问题,尤其是对于Swift这种还没有内置并发支持的语言来说线程安全问题更为突出。下面我们通过常见的数组操作来分析其中存在的线程问题,以及如何实现一个线程安全数组。因为对于值类型来说Swift采用的是copyOnWrite机制,所以在进行copyOnWrite处理是可能数组已经被另一个写操作给修改了。

  10. swift中的线程安全单例

    我有和应用程序有一个单一的存储整个应用程序的信息.但是,当使用来自不同线程的单例时,这会产生一些数据争用问题.这里有一个非常虚拟和简单化的问题版本:独生子单例的使用有没有办法确保单例是线程安全的,所以它可以在应用程序的任何地方使用,而不必担心你在哪个线程?

随机推荐

  1. 基于EJB技术的商务预订系统的开发

    用EJB结构开发的应用程序是可伸缩的、事务型的、多用户安全的。总的来说,EJB是一个组件事务监控的标准服务器端的组件模型。基于EJB技术的系统结构模型EJB结构是一个服务端组件结构,是一个层次性结构,其结构模型如图1所示。图2:商务预订系统的构架EntityBean是为了现实世界的对象建造的模型,这些对象通常是数据库的一些持久记录。

  2. Java利用POI实现导入导出Excel表格

    这篇文章主要为大家详细介绍了Java利用POI实现导入导出Excel表格,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下

  3. Mybatis分页插件PageHelper手写实现示例

    这篇文章主要为大家介绍了Mybatis分页插件PageHelper手写实现示例,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

  4. (jsp/html)网页上嵌入播放器(常用播放器代码整理)

    网页上嵌入播放器,只要在HTML上添加以上代码就OK了,下面整理了一些常用的播放器代码,总有一款适合你,感兴趣的朋友可以参考下哈,希望对你有所帮助

  5. Java 阻塞队列BlockingQueue详解

    本文详细介绍了BlockingQueue家庭中的所有成员,包括他们各自的功能以及常见使用场景,通过实例代码介绍了Java 阻塞队列BlockingQueue的相关知识,需要的朋友可以参考下

  6. Java异常Exception详细讲解

    异常就是不正常,比如当我们身体出现了异常我们会根据身体情况选择喝开水、吃药、看病、等 异常处理方法。 java异常处理机制是我们java语言使用异常处理机制为程序提供了错误处理的能力,程序出现的错误,程序可以安全的退出,以保证程序正常的运行等

  7. Java Bean 作用域及它的几种类型介绍

    这篇文章主要介绍了Java Bean作用域及它的几种类型介绍,Spring框架作为一个管理Bean的IoC容器,那么Bean自然是Spring中的重要资源了,那Bean的作用域又是什么,接下来我们一起进入文章详细学习吧

  8. 面试突击之跨域问题的解决方案详解

    跨域问题本质是浏览器的一种保护机制,它的初衷是为了保证用户的安全,防止恶意网站窃取数据。那怎么解决这个问题呢?接下来我们一起来看

  9. Mybatis-Plus接口BaseMapper与Services使用详解

    这篇文章主要为大家介绍了Mybatis-Plus接口BaseMapper与Services使用详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

  10. mybatis-plus雪花算法增强idworker的实现

    今天聊聊在mybatis-plus中引入分布式ID生成框架idworker,进一步增强实现生成分布式唯一ID,具有一定的参考价值,感兴趣的小伙伴们可以参考一下

返回
顶部