1. 超卖问题(多人秒杀)
1.1 原因
- 多线程并行运行
- 多行代码操作共享资源,但不具备原子性
例:
1.2 解决方案
针对并发安全问题,最广为人知的解决方案就是加锁。
从实现思想上来说,锁可以分为两大类:
- 悲观锁
- 乐观锁
悲观锁是一种独占和排他的锁机制,保守地认为数据会被其他事务修改,所以在整个数据处理过程中将数据处于锁定状态。
乐观锁是一种较为乐观的并发控制方法,假设多用户并发的不会产生安全问题,因此无需独占和锁定资源。但在更新数据前,会先检查是否有其他线程修改了该数据,如果有,则认为可能有风险,会放弃修改操作。
悲观锁、乐观锁是对并发安全问题的处理态度不同:
- 悲观锁认为安全问题一定会发生,所以直接独占资源。结果就是多个线程会串行执行被保护的代码。
- 优点:安全性非常高
- 缺点:性能较差
- 乐观锁则认为安全问题不一定发生,所以不独占资源。结果就是允许多线程并行执行。但如果真的发生并发修改怎么办??乐观锁采用CAS(Compare And Set)思想,在更新数据前先判断数据与我之前查询到的是否一致,不一致则证明有其它线程也在更新。为了避免出现安全问题,放弃本次更新或者重新尝试一次。
乐观锁:
- 优点:性能好、安全性也好
- 缺点:并发较高时,可能出现更新成功率较低的问题(并行的N个线程只会有1个成功)
1.3 总结
超卖这样的线程安全问题,解决方案有哪些?
- 悲观锁:添加同步锁,让线程串行执行
- 优点:简单粗暴
- 缺点:性能一般
- 乐观锁:不加锁,在更新时判断是否有其它线程在修改
- 优点:性能好
- 缺点:存在成功率低的问题
2. 锁失效问题(单人重复抢)
2.1 原因
使用Synchronized的代码块作为锁时,锁使用的是方法中的变量时,此时一般会通过tostring()方法将变量转为常量,但由于tostring的底层方法中使用的是:
这种new出来的对象并不相同,从而导致锁不相同,从而引发锁失效的问题。
2.2 解决方案
String类中提供了intern()方法:
从描述中可以看出,只要两个字符串equals的结果为true,那么intern就能保证得到的结果用 ==判断也是true,其原理就是获取字符串字面值对应到常量池中的字符串常量。因此只要两个字符串一样,intern()返回的一定是同一个对象。
3. 事务边界问题(单人重复抢)
3.1 原因
由于锁过早释放,导致了事务尚未提交,并发的线程判断出现错误,最终导致并发安全问题发生。
这其实就是事务边界和锁边界的问题。
3.2 解决方案
解决方案很简单,就是调整边界:
- 业务开始前,先获取锁,再开启事务
- 业务结束后:先提交事务,再释放锁
将加锁的部分抽取为一个方法,在方法上加@Transactional事务注解,在调用的方法中将抽取的方法放在锁内即可解决
3.3 总结
在事务和锁并行存在时,一定要考虑事务和锁的边界问题。由于事务的隔离级别问题,可能会导致不同事务之间数据不可见,往往会产生一些不可预期的现象。
4. 事务失效问题
4.1 原因
虽然事务边界问题已经解决,但是其解决方案也埋下了新的隐患。
常见的事务失效原因:
4.1.1 事务方法非public修饰
由于Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的,这样才能便于被Spring做事务的代理和增强。
而且,在Spring内部也会有一个 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource类,去检查事务方法的修饰符:
@Nullable
protected TransactionAttribute computeTransactionAttribute(
Method method, @Nullable Class<?> targetClass) {
// Don't allow non-public methods, as configured.
if (allowPublicMethodsOnly() &&
!Modifier.isPublic(method.getModifiers())) {
return null;
}
// ... 略
return null;
}
所以,事务方法一定要被public修饰!
4.1.2 非事务方法调用事务方法
@Service
public class OrderService {
public void createOrder(){
// ... 准备订单数据
// 生成订单并扣减库存
insertOrderAndReduceStock();
}
@Transactional
public void insertOrderAndReduceStock(){
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
}
}
可以看到,insertOrderAndReduceStock方法是一个事务方法,肯定会被Spring事务管理。Spring会给OrderService类生成一个动态代理对象,对insertOrderAndReduceStock方法做增加,实现事务效果。
但是现在createOrder方法是一个非事务方法,在其中调用了insertOrderAndReduceStock方法,这个调用其实隐含了一个this.的前缀。也就是说,这里相当于是直接调用原始的OrderService中的普通方法,而非被Spring代理对象的代理方法。那事务肯定就失效了!
4.1.3 事务方法的异常被捕获了
示例:
@Service
public class OrderService {
@Transactional
public void createOrder(){
// ... 准备订单数据
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
}
private void reduceStock() {
try {
// ...扣库存
} catch (Exception e) {
// 处理异常
}
}
}
在这段代码中,reduceStock方法内部直接捕获了Exception类型的异常,也就是说方法执行过程中即便出现了异常也不会向外抛出。
而Spring的事务管理就是要感知业务方法的异常,当捕获到异常后才会回滚事务。
现在事务被捕获,就会导致Spring无法感知事务异常,自然不会回滚,事务就失效了。
4.1.4 事务异常类型不对
@Service
public class OrderService {
@Transactional(rollbackFor = RuntimeException.class)
public void createOrder() throws IOException {
// ... 准备订单数据
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
throw new IOException();
}
}
Spring的事务管理默认感知的异常类型是RuntimeException,当事务方法内部抛出了一个IOException时,不会被Spring捕获,因此就不会触发事务回滚,事务就失效了。
因此,当我们的业务中会抛出RuntimeException以外的异常时,应该通过@Transactional注解中的rollbackFor属性来指定异常类型:
@Transactional(rollbackFor = Exception.class)
4.1.5 事务传播行为不对
@Service
public class OrderService {
@Transactional
public void createOrder(){
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
throw new RuntimeException("业务异常");
}
@Transactional
public void insertOrder() {
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void reduceStock() {
}
}
在示例代码中,事务的入口是createOrder()方法,会开启一个事务,可以成为外部事务。在createOrder()方法内部又调用了insertOrder()方法和reduceStock()方法。这两个都是事务方法。
不过,reduceStock()方法的事务传播行为是REQUIRES_NEW,这会导致在进入reduceStock()方法时会创建一个新的事务,可以成为子事务。insertOrder()则是默认,因此会与createOrder()合并事务。
因此,当createOrder方法最后抛出异常时,只会导致insertOrder方法回滚,而不会导致reduceStock方法回滚,因为reduceStock是一个独立事务。
所以,一定要慎用传播行为,注意外部事务与内部事务之间的关系。文章来源:https://www.toymoban.com/news/detail-613585.html
4.1.6 没有被Spring管理
// @Service
public class OrderService {
@Transactional
public void createOrder(){
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
throw new RuntimeException("业务异常");
}
@Transactional
public void insertOrder() {
}
@Transactional
public void reduceStock() {
}
}
这个示例属于比较低级的错误,OrderService类没有添加@Service注解,因此就没有被Spring管理。你在方法上添加的@Transactional注解根本不会有人帮你动态代理,事务自然失效。文章来源地址https://www.toymoban.com/news/detail-613585.html
到了这里,关于超卖等高并发秒杀场景的问题及解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!