导致JVM本地锁失效的3种情况

来讨论一下导致JVM本地锁失效的3种情况吧

前言

一般我们最常用的Java中的锁有 synchronized 和 ReentrantLock , synchronized是jvm内置的锁, ReentrantLock是api级别的 效率上基本差不多 因为synchronized 也已经有了不少的优化比如锁升级操作等.., ReentrantLock会更加灵活高级

下面我会用一个扣减库存的案例来演示日常开发中需要注意的导致锁失效的方式.

首先数据库准备一个 count = 5000 的商品

无锁

下面是一个简单的扣减库存的操作并且没有添加锁的控制

public void deduct() {
    ProductLockEntity productLockEntity =
            productLockMapper.selectOne(
                    new LambdaQueryWrapper<ProductLockEntity>()
                            .eq(ProductLockEntity::getProductCode, "1001"));
    if (productLockEntity != null && productLockEntity.getCount() > 0) {
        productLockEntity.setCount(productLockEntity.getCount() - 1);
        productLockMapper.updateById(productLockEntity);
    }
}

ab测试并发测试一下 , 发现 count 出现了并发问题没有扣减为 0

ab -c 100 -n 5000 http://127.0.0.1:10010/deduct

上面是因为没有锁的控制导致并且请求进来比如线程1 查询商品count = 5000 线程2 也查询到商品count = 5000

都进行了 count -1 = 4999操作 , 并且都更新了数据库,从而产生了扣减库存错误问题.

添加锁

在方法上添加了 synchronized 锁来控制这个方法每次只有一个线程执行

public synchronized void deduct() {
    ProductLockEntity productLockEntity =
            productLockMapper.selectOne(
                    new LambdaQueryWrapper<ProductLockEntity>()
                            .eq(ProductLockEntity::getProductCode, "1001"));
    //判断商品count数量 > 0 就执行扣减操作 更新数据库
    if (productLockEntity != null && productLockEntity.getCount() > 0) {
        productLockEntity.setCount(productLockEntity.getCount() - 1);
        productLockMapper.updateById(productLockEntity);
    }
}

把count调回到5000 后再次 ab 并发测试一下 , 发现 count 扣减为 0

ab -c 100 -n 5000 http://127.0.0.1:10010/deduct

上面看似是没啥问题了但是有几种情况会导致锁失效

第一种导致锁失效情况之 `多例模式`

一般我们都会使用 Spring框架来做后端的web开发, 那spring中默认的bean 是单例的, 也就是只有一个service对象

那么在使用synchronized控制方法的时候每个线程都是拿的同一把锁不会产生问题, 如果 service对象是多例的,那么锁都不一样了就无法控制并发问题了

下面演示synchronized锁和 ReentrantLock锁在多例模式下失效的情况

//synchronized锁

@Service
//注意 需要指定proxyMode=TARGET_CLASS 因为使用的 jdk动态代理 这里没有写 service接口
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ProductLockService {

    @Autowired private ProductLockMapper productLockMapper;

    public synchronized void deduct() {
        ProductLockEntity productLockEntity =
                productLockMapper.selectOne(
                        new LambdaQueryWrapper<ProductLockEntity>()
                                .eq(ProductLockEntity::getProductCode, "1001"));
        if (productLockEntity != null && productLockEntity.getCount() > 0) {
            productLockEntity.setCount(productLockEntity.getCount() - 1);
            productLockMapper.updateById(productLockEntity);
        }
    }
}

//ReentrantLock 锁
@Service
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ProductLockService {

    @Autowired private ProductLockMapper productLockMapper;
    //由于ProductLockService 是多例 所以这里的锁 也不是同一个对象了
    private ReentrantLock lock = new ReentrantLock();

    
    public void deduct() {
        lock.lock();
        try {
            ProductLockEntity productLockEntity =
                    productLockMapper.selectOne(
                            new LambdaQueryWrapper<ProductLockEntity>()
                                    .eq(ProductLockEntity::getProductCode, "1001"));
            if (productLockEntity != null && productLockEntity.getCount() > 0) {
                productLockEntity.setCount(productLockEntity.getCount() - 1);
                productLockMapper.updateById(productLockEntity);
            }
        } finally {
            lock.unlock();
        }
    }
}

//ProductLockController
@Autowired private ProductLockService productLockService;
@GetMapping("/deduct")
public void deduct() {
    log.info("productLockService: {} ", productLockService);
    productLockService.deduct();
}

再次 ab 并发测试一下 , 发现 count 又出现了并发问题

这就是导致JVM本地锁失效的第一种情况

第二种导致锁失效情况之 `事物`

下面来看看事物的使用错误也会导致锁失效的情况

恢复到单例模式下 代码如下: 可以发现好像没啥问题也是单例也添加了锁真的是这样吗?

...
private ReentrantLock lock = new ReentrantLock();
@Transactional
public void deduct() {
    lock.lock();
    try {
        ProductLockEntity productLockEntity =
                productLockMapper.selectOne(
                        new LambdaQueryWrapper<ProductLockEntity>()
                                .eq(ProductLockEntity::getProductCode, "1001"));
        if (productLockEntity != null && productLockEntity.getCount() > 0) {
            productLockEntity.setCount(productLockEntity.getCount() - 1);
            productLockMapper.updateById(productLockEntity);
        }
    } finally {
        lock.unlock();
    }
}

ab测试并发测试一下 , 发现 count 出现了并发问题没有扣减为 0

这是为什么呢??? 因为添加了 @Transactional 这个方法结束后都释放了锁后才 commit 提交事物 , 而在锁释放后未提交事物之前 其他线程查询到的数据还是以前的count数量 (因为前面的线程还未提交事物)(因为MySQL 的默认隔离级别是可重复读) 这又会导致更新重复问题 ..

那应该怎么改进呢? 应该先执行完事物再释放锁, 可以把释放锁操作放到事物方法的后面代码如下:

    @Transactional
    public void deduct() {
        ProductLockEntity productLockEntity =
                productLockMapper.selectOne(
                        new LambdaQueryWrapper<ProductLockEntity>()
                                .eq(ProductLockEntity::getProductCode, "1001"));
        if (productLockEntity != null && productLockEntity.getCount() > 0) {
            productLockEntity.setCount(productLockEntity.getCount() - 1);
            productLockMapper.updateById(productLockEntity);
        }
    }

//调用出 添加锁
    @GetMapping("/deduct")
    public void deduct() {
        lock.lock();
        try {
            productLockService.deduct();
        } finally {
            //此时释放锁 deduct方法已经执行完毕 并且事物已经提交了
            lock.unlock();
        }
    }