Synchronized或Lock与Transcational搭配使用导致并发问题

207 篇文章 8 订阅 ¥129.90 ¥299.90
当Synchronized或Lock与@Transactional注解一起使用时,可能导致并发问题。文章通过一个并发测试例子展示了库存超卖的情况,解释了由于事务处理顺序和锁的使用不当,使得其他线程有机会在事务提交前读取旧数据。解决方案是确保事务和锁的范围正确,比如将事务逻辑包含在锁的范围内,或者调整服务调用方式。
摘要由CSDN通过智能技术生成

在多线程的情况下,我们经常会用到synchronized或者Lock来保证我们的线程安全。
但是当碰到Transcational之后又会碰撞出什么火花呢?

相信我,看完之后,你一定不会亏

首先回顾一下小知识点:
基于@Transactional注解的是 声明式事务
spring还提供了另外一种创建事务的方式,即通过手动编写代码实现的事务,我们把这种事务叫做:编程式事务。

数据库连接本来默认是自动提交的,加上注解Transactional之后,会设置为手动提交。
自动提交意味着 每当我们执行一个update ,delete或者insert的时候都会自动提交到数据库,无法回滚事务。

下面我们来看一个例子:

这个方法的执行流程是这样的。

很显然,涉及库存和订单,都会对数据库进行操作,且应该是应该原子性的操作。

所以我们在方法上加了一个 @Transactional 注解。

接着我们用Jmeter进行并发测试 15个线程 抢购数据库现有的10个库存。

执行完之后,我们发现本来10台库存,现在15个人居然都抢到了,还剩了2台。
真是离谱Mother给离谱开门,离谱到家了。此刻我真的想说,I love you Mother。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

瑆箫

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值