【Java】事务套着锁，ReentrantLock【可重入互斥锁】

问题：Java中已经加了锁，为什么结果却还是超卖？

• 加锁：模拟使用ReentrantLock加锁，多线程下建议使用Redisson分布式锁实现
• 超卖：是指系统允许多个用户购买或预订超过实际可用数量的资源

---

主要目标

实现四大重点

1. 什么是超卖
2. 超卖如何解决
3. 事务套锁失效问题
4. 解决锁失效问题

一、情景前置

1.1 空调租赁充值时长超卖问题

1.2 设备表

CREATE TABLE `device` (
  `id` bigint(20) NOT NULL COMMENT '主键',
  `use_times` int(10) DEFAULT '0' COMMENT '使用时长',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

二、目标分析

2.1 什么是超卖？

系统允许多个用户购买或预订超过实际可用数量的资源.
解释说明:
结合上述情景前置，就是宿舍这100个人同时并发操作，按照正常逻辑每个人充值都会在基数+1小时，则总使用时长应为100。

但因为多线程并发问题，可能会导致A和B同时处理逻辑时，获取基数都是同一个，+1后同时更新入库，这样最终的总使用时长就会小于100，出现超卖问题。

出现超卖的代码

@GetMapping("/A")
@Operation(summary = "方式A-更新设备-普通方法(会出现超卖)")
public void payA(@RequestParam Long deviceId) throws InterruptedException {
    for(int i=0; i<100; i++){
        // 暂停20毫秒，模拟不同时间，不同人请求并发
        Thread.sleep(20);
        // 模拟是个100线程
        new Thread(() -> {
            // 更新设备-普通方法
            deviceService.updateDeviceNormal(deviceId);
        }).start();
    }
}

@Override
public void updateDeviceNormal(Long deviceId) {
    Device device = this.getById(deviceId);
    LambdaUpdateWrapper<Device> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper.eq(Device::getId, deviceId);
    updateWrapper.set(Device::getUseTimes, device.getUseTimes()+1);
    this.update(updateWrapper);
}

2.2 出现超卖的代码

出现超卖的代码截图


出现超卖的代码调试

三、如何解决超卖问题

1. 乐观锁 通常通过在数据库表中增加一个版本号（version）字段来实现。在更新时，系统会检查当前版本号是否与请求时的版本号相匹配，如果匹配则更新，否则认为数据已被其他事务修改，当前事务失败。
2. 悲观锁 在数据被读取时就锁定数据，直到事务结束。在数据库中，可以通过SELECT … FOR UPDATE语句来实现，这会阻止其他事务对锁定的数据进行修改，直到当前事务完成。
3. 分布式锁 在分布式系统中，单个节点的锁机制不足以保证数据的一致性，因此需要使用分布式锁，如Redisson
4. 代码锁 使用 synchronized 关键字或者使用 ReentrantLock等

3.1 什么是ReentrantLock?

解决方式有很多种，举例以ReentrantLock为例，首先了解什么是ReentrantLock?

ReentrantLock 是 Java 平台上的一个可重入的互斥锁，它属于 java.util.concurrent.locks 包的一部分。与传统的 synchronized 关键字相比，ReentrantLock 提供了更多高级功能和更大的灵活性。
什么是可重入的互斥锁？
可重入的互斥锁是一种特殊的锁机制，它允许在同一个线程内多次获取而不造成死锁。通常，互斥锁（mutex）在一个线程获取后，会阻止其他线程获取该锁，直到锁被释放。然而，可重入的互斥锁允许一个线程在已经获取了锁的情况下再次获取锁，而不会引起死锁，而是增加锁的持有计数。当这个线程最终释放锁时，它必须释放相同的次数才能完全释放锁，让其他线程有机会获取。

3.2 加入ReentrantLock代码

@GetMapping("/B")
@Operation(summary = "方式B-更新设备-使用ReentrantLock(不会出现超卖)")
public void payB(@RequestParam Long deviceId) throws InterruptedException {
    // 模拟是个10线程
    for(int i=0; i<100; i++){
        // 暂停20毫秒，模拟不同时间，不同人请求并发
        Thread.sleep(20);
        // 创建线程
        new Thread(() -> {
            // 更新设备-使用ReentrantLock。
            deviceService.updateDeviceByLock(deviceId);
        }).start();
    }
}

Lock lock = new ReentrantLock();
@Override
public void updateDeviceByLock(Long deviceId) {
    lock.lock();
    Device device = this.getById(deviceId);
    LambdaUpdateWrapper<Device> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper.eq(Device::getId, deviceId);
    updateWrapper.set(Device::getUseTimes, device.getUseTimes()+1);
    try {
        this.update(updateWrapper);
    } catch (Exception e) {
        throw new RuntimeException(e);
    } finally {
        lock.unlock();
    }
}

加入ReentrantLock代码截图


ReentrantLock代码调试

四、事务套锁失效问题

上面第二步已经通过加入ReentrantLock成功解决超卖问题

4.1 锁外面加入事务@Transactional依然存在超卖

事务套锁失效代码

@GetMapping("/C")
@Operation(summary = "方式C-更新设备-使用事务套锁(锁失效)")
public void payC(@RequestParam Long deviceId) throws InterruptedException {
    for(int i=0; i<100; i++){
        // 暂停20毫秒，模拟不同时间，不同人请求并发
        Thread.sleep(20);
        // 模拟是个100线程
        new Thread(() -> {
            // 更新-使用事务套锁
            deviceService.updateDeviceByTansaction(deviceId);
        }).start();
    }
}

@Override
@Transactional(rollbackFor = Exception.class)
public void updateDeviceByTansaction(Long deviceId) {
    // 加锁
    lock.lock();
    Device device = this.getById(deviceId);
    LambdaUpdateWrapper<Device> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper.eq(Device::getId, deviceId);
    updateWrapper.set(Device::getUseTimes, device.getUseTimes()+1);
    try {
        this.update(updateWrapper);
    } catch (Exception e) {
        throw new RuntimeException(e);
    } finally {
        // 解锁
        lock.unlock();
    }
}

事务套锁失效代码截图


事务套锁失效代码调试

4.2 为什么加入事务就导致锁失效了呢？

答案是因为事务边界问题

使用@Transactional 注解来管理事务，但锁的获取和释放并没有放在事务边界之内。这意味着如果在事务提交之前锁就被释放了，其他线程可能在当前事务结束之前修改相同的数据，这会导致数据不一致。

4.3 解决锁失效问题

通过上面分析事务套锁失效问题，我们可以采取事务边界缩小，尽量不要让事务边界过大，从而导致包裹着锁导致并发数据问题
事务边界缩小代码

@GetMapping("/D")
@Operation(summary = "方式D-更新设备-缩小事务便捷方法(锁正常-不会出现超卖)")
public void payD(@RequestParam Long deviceId) throws InterruptedException {
    for(int i=0; i<100; i++){
        // 暂停20毫秒，模拟不同时间，不同人请求并发
        Thread.sleep(20);
        // 模拟是个100线程
        new Thread(() -> {
            // 更新-使用原子性更新
            deviceService.updateDeviceByReduce(deviceId);
        }).start();
    }
}

@Override
public void updateDeviceByReduce(Long deviceId) {
     try {
         // 加锁
         lock.lock();
         this.updateDevice(deviceId);
     } finally {
         // 解锁
         lock.unlock();
     }
 }

 @Transactional(rollbackFor = Exception.class)
 public void updateDevice(Long deviceId){
     Device device = this.getById(deviceId);
     LambdaUpdateWrapper<Device> updateWrapper = new LambdaUpdateWrapper<>();
     updateWrapper.eq(Device::getId, deviceId);
     updateWrapper.set(Device::getUseTimes, device.getUseTimes()+1);
     this.update(updateWrapper);
 }

事务边界缩小代码截图


事务边界缩小代码调试

总结

处理并发和超卖问题时，理解并合理运用锁机制和事务管理至关重要。

通过将锁操作置于事务边界内，可以有效防止数据不一致，确保系统的稳定性和可靠性。

在实际应用中，根据业务特性和性能要求选择最合适的解决方案是关键

解决方案概述

• 乐观锁：通过版本号或时间戳检查数据是否已被其他事务修改，适用于读多写少的场景。
• 悲观锁：预先锁定数据直至事务完成，适合写操作频繁或数据竞争激烈的场景。
• 分布式锁：如Redisson，确保分布式系统中数据的一致性，适用于跨节点的数据同步。
• 代码级锁：利用synchronized或ReentrantLock等机制，控制线程间的访问顺序，防止并发冲突。
  事务边界的重要性
• 关键点：确保锁的获取和释放严格位于事务边界内，避免数据在事务未完成前被其他线程修改。
• 实践：使用try-finally结构包裹锁的获取和释放，确保即使发生异常，锁也能正确释放，维护数据完整性。