天机学堂第11天 超卖问题 ，锁失效，事务失效问题

超卖问题

2000个用户发起领取优惠卷请求

经过测试，确实出现了超卖（或超发）的现象，优惠只有100个库存，结果发放了109张券！！

那么，为什么出现了超卖的现象呢？

分析原因

现在我们对于优惠券库存的处理逻辑是这样的：

• 查询优惠券

• 判断库存是否充足（领取数量<总数量）

• 如果充足，更新优惠券领取数量

 进行压测时，发现产生了超卖

这里采用的是先查询，再判断，再更新的方案，而以上三步操作并不具备原子性。单线程的情况下确实没有问题。但如果是多线程并发运行，如果N个线程同时去查询（N大于剩余库存），此时大概率查询到的库存是充足的，然后判断库存自然没问题。最后一起更新库存，自然就会超卖 

 

总结一下，原因是：

• 多线程并行运行

• 多行代码操作共享资源，但不具备原子性

解决方案 

针对并发安全问题，最广为人知的解决方案就是加锁。不过，加锁的方式多种多样，大家熟悉的Synchronized、ReentrantLock只是其中最基础的锁。

何为悲观锁？

悲观锁是一种独占和排他的锁机制，保守地认为数据会被其他事务修改，所以在整个数据处理过程中将数据处于锁定状态。

何为乐观锁？

乐观锁是一种较为乐观的并发控制方法，假设多用户并发的不会产生安全问题，因此无需独占和锁定资源。但在更新数据前，会先检查是否有其他线程修改了该数据，如果有，则认为可能有风险，会放弃修改操作

• 悲观锁认为安全问题一定会发生，所以直接独占资源。结果就是多个线程会串行执行被保护的代码。

  • 优点：安全性非常高

  • 缺点：性能较差

• 乐观锁则认为安全问题不一定发生，所以不独占资源。结果就是允许多线程并行执行。但如果真的发生并发修改怎么办？？乐观锁采用CAS（Compare And Set）思想，在更新数据前先判断数据与我之前查询到的是否一致，不一致则证明有其它线程也在更新。为了避免出现安全问题，放弃本次更新或者重新尝试一次。

• 

• 这种方式高并发的时候虽然有库存，但成功率较低，老是失败

• 

不过，针对更新成功率低的问题，在优惠券库存这个业务中，有一个乐观锁的改进方案：

我们无需判断issue_num是否与原来一致，只要判断issue_num是否小于total_num即可。这样，只要issue_num小于total_num，不管有多少线程来执行，都会成功。

 需要注意的是，where条件不成立不会报错，而是更新失败，返回0. 因此，我们还应该对这个方法的返回值做判断，如果返回值是0，则应该抛出异常，触发回滚。

超卖这样的线程安全问题，解决方案有哪些？

• 悲观锁：添加同步锁，让线程串行执行（直接在方法上家加Synchronized）

  • 优点：简单粗暴

  • 缺点：性能一般

• 乐观锁：不加锁，在更新时判断是否有其它线程在修改

  • 优点：性能好

  • 缺点：存在成功率低的问题

 

锁失效问题

当单个用户，发送压测请求领取优惠卷时：

其实，除了优惠券库存判断，领券时还有对于用户限领数量的判断：

可以看到，这部分逻辑也是按照三步走：

• 查询数据库

• 判断是否超出限领数量

• 新增用户券

这段代码没有加锁，不具备原子性，如果多线程并发访问，肯定会出现安全问题。

怎么办？

是不是跟上节课一样，使用乐观锁解决？

显然不行，因为乐观锁常用在更新，而且这里用户和优惠券的关系并不具备唯一性，因此新增时无法基于乐观锁做判断。

所以，这里只能采用悲观锁方案，也就是大家熟悉的Synchronized或者Lock.

锁对象问题

用户限领数量判断是针对单个用户的，因此锁的范围不需要是整个方法，只要锁定某个用户即可。所以这里建议采用Synchronized的代码块，而不是同步方法。并且同步代码块的锁指定为用户id，那么同一个用户并发操作时会被锁定，不同用户互相没有影响，整体效率也是可以接受的。

锁用户id

经过测试，发现并发安全问题依然存在，锁没有生效！！！什么情况？

加了锁，但锁没生效，可能的原因是什么？答案是用了不同的锁。

使用long  interget 也是 只有-128~127 才是一样的 其他都需要new

我们期望同一个用户用同一把锁，那就要去锁对象必须是同一个。但是我们刚才的锁是userId.toString();

userId是Long类型，其中toString方法源码如下：

可以看到，这里竟然采用的是new String()的方式。

也就是说，哪怕是同一个用户，其id是一样，但toString()得到的也是多个不同对象！也就是多把不同的锁！

intern

只要两个字符串equals的结果为true，那么intern就能保证得到的结果用 ==判断也是true，其原理就是获取字符串字面值对应到常量池中的字符串常量。因此只要两个字符串一样，intern()返回的一定是同一个对象。

 

事务边界问题

经过同步锁的改造，理论上用户限领数量判断的逻辑应该已经是解决了。

不过，经过测试后，发现问题依然存在，用户还是会超领。这又是怎么回事呢？

 

分析原因

其实这次的问题并不是由于锁导致的，而是由于事务的隔离导致。

要知道，整个领券发放是加了事务的：

注意，这里是先开启事务，再获取锁；而业务执行完毕后，是先释放锁，再提交事务。 

整个流程是这样的，线程2在线程1释放了锁但没提交事务之前进行了查询

 

解决方案

解决方案很简单，就是调整边界：

• 业务开始前，先获取锁，再开启事务

• 业务结束后：先提交事务，再释放锁

 非事务调用事务，这样保证先开启锁 然后开启事务（这样虽然解决了并发，但是却让事务失效了，解决办法就是暴露代理，直接调用代理里面的方法）

 

由于事务方法需要public修饰，并且被spring管理。因此要把事务方法向上抽取到service接口中：

在事务和锁并行存在时，一定要考虑事务和锁的边界问题。由于事务的隔离级别问题，可能会导致不同事务之间数据不可见，往往会产生一些不可预期的现象。 

事务失效问题

虽然解决了并发安全问题，但其实我们的改造却埋下了另一个隐患。当事务方法抛出异常时发现事务没有回滚，这说明事务没有生效。这就属于 事务失效原因值 非事务调用事务方法，因为是调用的this里面的方法（this是隐式的）相当于调用了普通方法

分析原因

事务方法非public修饰

由于Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的，这样才能便于被Spring做事务的代理和增强。

非事务方法调用事务方法

可以看到，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无法感知事务异常，自然不会回滚，事务就失效了。

事务异常类型不对

事务传播行为不对

没有被Spring管理 

 解决办法

结合上节课的分析，大家应该能发现我们的事务失效的原因是什么了。

为了控制事务边界，我们改变了事务注解标记的位置，这就导致了非事务方法调用了事务方法。

怎么办？难道再把注解移回去？

这显然不合适，因为移回去就会导致并发安全问题。我们陷入了两难境地。

那么，有没有办法让这个事务再次生效呢？

答案是有的，既然事务失效的原因是方法内部调用走的是this，而不是代理对象。那我们只要想办法获取代理对象不就可以了嘛。

1）引入AspectJ依赖

<!--aspecj-->
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
</dependency>

这个注解默认就是有的 但是里面的exposeproxy默认是false