在一个对优惠价领取的场景中有以下步骤:
- 查询数据库
- 判断是否超出限领数量
- 新增用户券
为避免超卖问题,我们对其进行加锁,用户限领数量判断是针对单个用户的,因此锁的范围不需要是整个方法,**只要锁定某个用户即可。**并且同步代码块的锁指定为用户id,那么同一个用户并发操作时会被锁定,不同用户互相没有影响,整体效率也是可以接受的。
public void checkAndCreateUserCoupon(Long userId, Coupon coupon,Long serialNum) {
synchronized (userId.toString()){
Integer count = this.lambdaQuery()
.eq(UserCoupon::getUserId, userId)
.eq(UserCoupon::getCouponId, coupon.getId())
.count();
if(count!=null&&count>=coupon.getUserLimit()){
throw new BadRequestException("已达到领取上限");
}
couponMapper.incrIssueNum(coupon.getId());//采用这种方式,考虑并发控制,后期仍需修改
//3.生成用户卷
saveUserCoupon(userId,coupon);
if(serialNum!=null){
//修改兑换码的状态
exchangeCodeService.lambdaUpdate()
.eq(ExchangeCode::getId,serialNum)
.set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
.set(ExchangeCode::getUserId,userId)
.update();
}
}
}
这里有个坑,我们测试会发现锁并没有生效,为什么呢?
答案是用了不同的锁。
我们期望同一个用户用同一把锁,那就要去锁对象必须是同一个。但是我们刚才的锁是userId.toString()
;
userId是Long类型,其中toString方法源码如下:
可以看到,这里竟然采用的是new String()的方式。
也就是说,哪怕是同一个用户,其id是一样,但toString()得到的也是多个不同对象!也就是多把不同的锁!
怎么解决呢?
解决方案
String类中提供了一个intern()
方法:
只要两个字符串equals的结果为true,那么intern就能保证得到的结果用 ==判断也是true,**其原理就是获取字符串字面值对应到常量池中的字符串常量。**因此只要两个字符串一样,intern()返回的一定是同一个对象。
因此,我们这样改造:
事务边界问题
经过同步锁的改造,理论上用户限领数量判断的逻辑应该已经是解决了。
不过,经过测试后,发现问题依然存在,用户还是会超领。这又是怎么回事呢?
分析原因
其实这次的问题并不是由于锁导致的,而是由于事务的隔离导致。
要知道,整个领券发放是加了事务的:
注:刚刚说的那个方法,是这个方法中的子方法。
而在发放内部,我们加锁,处理限领数量的判断。
整体业务流程是这样的:
- 开启事务
- 获取锁
- 统计用户已领券的数量
- 判断是否超出限领数量
- 如果没超,新增一条用户券
- 释放锁
- 提交事务
注意,这里是先开启事务,再获取锁;而业务执行完毕后,是先释放锁,再提交事务。
假如用户限领数量为1,当前用户没有领过券。但是这个人写了一个抢券程序,用自己的账号并发的来访问我们。
假设此时有两个线程并行执行这段逻辑:
-
线程1开启事务,然后获取锁成功;线程2开启事务,但是获取锁失败,被阻塞
-
线程1执行业务,由于没领过,所有业务都能正常执行,不再赘述
-
线程1释放锁。此时线程2立刻获取锁成功,开始执行业务:
- 线程2统计用户已领取数量。由于线程1尚未提交事务,此时线程2读取不到未提交数据。因此认为当前用户没有领券。
- 判断限领数量通过,于是也新增一条券
- 安全问题发生了!
总结:由于锁过早释放,导致了事务尚未提交,判断出现错误,最终导致并发安全问题发生。
这其实就是事务边界和锁边界的问题。
3.3.2.解决方案
解决方案很简单,就是调整边界:
- 业务开始前,先获取锁,再开启事务
- 业务结束后:先提交事务,再释放锁
具体代码如下:
// 。。。略
@Service
@RequiredArgsConstructor
public class UserCouponServiceImpl extends ServiceImpl<UserCouponMapper, UserCoupon> implements IUserCouponService {
private final CouponMapper couponMapper;
private final IExchangeCodeService codeService;
@Override
// @Transactional 此处的事务注解取消
public void receiveCoupon(Long couponId) {
// 1.查询优惠券
Coupon coupon = couponMapper.selectById(couponId);
if (coupon == null) {
throw new BadRequestException("优惠券不存在");
}
// 2.校验发放时间
LocalDateTime now = LocalDateTime.now();
if (now.isBefore(coupon.getIssueBeginTime()) || now.isAfter(coupon.getIssueEndTime())) {
throw new BadRequestException("优惠券发放已经结束或尚未开始");
}
// 3.校验库存
if (coupon.getIssueNum() >= coupon.getTotalNum()) {
throw new BadRequestException("优惠券库存不足");
}
Long userId = UserContext.getUser();
// 4.校验并生成用户券
synchronized(userId.toString().intern()){ // 这里加锁,这样锁在事务之外
checkAndCreateUserCoupon(coupon, userId, null);
}
}
@Transactional // 这里进事务,同时,事务方法一定要public修饰
public void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum){
// 1.校验每人限领数量
// 1.1.统计当前用户对当前优惠券的已经领取的数量
Integer count = lambdaQuery()
.eq(UserCoupon::getUserId, userId)
.eq(UserCoupon::getCouponId, coupon.getId())
.count();
// 1.2.校验限领数量
if (count != null && count >= coupon.getUserLimit()) {
throw new BadRequestException("超出领取数量");
}
// 2.更新优惠券的已经发放的数量 + 1
int r = couponMapper.incrIssueNum(coupon.getId());
if (r == 0) {
throw new BizIllegalException("优惠券库存不足");
}
// 3.新增一个用户券
saveUserCoupon(coupon, userId);
// 4.更新兑换码状态
if (serialNum != null) {
codeService.lambdaUpdate()
.set(ExchangeCode::getUserId, userId)
.set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
.eq(ExchangeCode::getId, serialNum)
.update();
}
}
private void saveUserCoupon(Coupon coupon, Long userId) {
// 1.基本信息
UserCoupon uc = new UserCoupon();
uc.setUserId(userId);
uc.setCouponId(coupon.getId());
// 2.有效期信息
LocalDateTime termBeginTime = coupon.getTermBeginTime();
LocalDateTime termEndTime = coupon.getTermEndTime();
if (termBeginTime == null) {
termBeginTime = LocalDateTime.now();
termEndTime = termBeginTime.plusDays(coupon.getTermDays());
}
uc.setTermBeginTime(termBeginTime);
uc.setTermEndTime(termEndTime);
// 3.保存
save(uc);
}
// 。。。 略
}
由于事务方法需要public修饰,并且被spring管理。因此要把事务方法向上抽取到service接口中:
import com.baomidou.mybatisplus.extension.service.IService;
import com.tianji.promotion.domain.po.UserCoupon;
import java.util.List;
/**
* <p>
* 用户领取优惠券的记录,是真正使用的优惠券信息 服务类
* </p>
*
* @author 虎哥
*/
public interface IUserCouponService extends IService<UserCoupon> {
void receiveCoupon(Long couponId);
void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum);
}
总结
在事务和锁并行存在时,一定要考虑事务和锁的边界问题。由于事务的隔离级别问题,可能会导致不同事务之间数据不可见,往往会产生一些不可预期的现象。
事务失效问题
虽然解决了并发安全问题,但其实我们的改造却埋下了另一个隐患。一起测试一下。
我们在领券业务的最后故意抛出一个异常:
经过测试,发现虽然抛出了异常,但是库存、用户券都没有回滚!事务失效了!
分析原因
事务失效的原因有很多,接下来我们就逐一分析一些常见的原因:
事务方法非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;
}
非事务方法调用事务方法
有这样一段代码:
@Service
public class OrderService {
public void createOrder(){
// ... 准备订单数据
// 生成订单并扣减库存
insertOrderAndReduceStock();
}
@Transactional
public void insertOrderAndReduceStock(){
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
}
}
可以看到,insertOrderAndReduceStock
方法是一个事务方法,肯定会被Spring事务管理。Spring会给OrderService
类生成一个动态代理对象,对insertOrderAndReduceStock
方法做增加,实现事务效果。
但是现在createOrder
方法是一个非事务方法,在其中调用了insertOrderAndReduceStock
方法,这个调用其实隐含了一个this.
的前缀。也就是说,这里相当于是直接调用原始的OrderService中的普通方法,而非被Spring代理对象的代理方法。那事务肯定就失效了!
事务方法的异常被捕获了
示例:
@Service
public class OrderService {
@Transactional
public void createOrder(){
// ... 准备订单数据
// 生成订单
insertOrder();
// 扣减库存
reduceStock();
}
private void reduceStock() {
try {
// ...扣库存
} catch (Exception e) {
// 处理异常
}
}
}
在这段代码中,reduceStock方法内部直接捕获了Exception类型的异常,也就是说方法执行过程中即便出现了异常也不会向外抛出。
而Spring的事务管理就是要感知业务方法的异常,当捕获到异常后才会回滚事务。
现在事务被捕获,就会导致Spring无法感知事务异常,自然不会回滚,事务就失效了。
事务异常类型不对
示例代码:
@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)
事务传播行为不对
原理:Spring 事务传播的底层实现主要依赖于 AOP(面向切面编程)和事务管理器。具体来说,Spring 使用代理模式,在方法调用前后插入事务管理逻辑。通过切面拦截方法调用,Spring 根据配置的传播行为(如 REQUIRES_NEW、REQUIRED 等)决定如何处理当前事务。例如,如果当前存在事务,REQUIRED 会加入该事务;而 REQUIRES_NEW 会暂停当前事务,创建一个新事务。最终,Spring 通过 PlatformTransactionManager 接口与底层事务管理框架(如 JDBC、JPA)进行交互,以管理事务的提交和回滚。
比如:
@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
是一个独立事务。
所以,一定要慎用传播行为,注意外部事务与内部事务之间的关系。
没有被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
注解根本不会有人帮你动态代理,事务自然失效。
解决方案
结合上节课的分析,大家应该能发现我们的事务失效的原因是什么了。
为了控制事务边界,我们改变了事务注解标记的位置,这就导致了非事务方法调用了事务方法。
怎么办?难道再把注解移回去?
这显然不合适,因为移回去就会导致并发安全问题。我们陷入了两难境地。
那么,有没有办法让这个事务再次生效呢?
答案是有的,既然事务失效的原因是方法内部调用走的是this,而不是代理对象。那我们只要想办法获取代理对象不就可以了嘛。
这里,我们可以借助AspectJ来实现。
1)引入AspectJ依赖:
<!--aspecj-->
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
</dependency>
2)暴露代理对象
在启动类上添加注解,暴露代理对象:
3)使用代理对象
最后,改造领取优惠券的代码,获取代理对象来调用事务方法:
问题解决。