基于 Spring 声明式事务下锁失效的场景分析
在开发的过程中，使用事务与锁是解决一些问题最常用的方式，但是当这俩个结合起来你真的会用吗？在高并发的场景下会出现哪些问题？要如何避免这些问题？接下来，带你了解事务与锁之间真正的打开方式。
示例
开发过程中，扣减库存是最经典的场景之一，接下来以此场景模拟扣减库存的代码实现
场景模拟
// 实体
@Data
public class MaterialStock {
/**
* 物料库存id
*/
private Long id;
/**
* 物料名称
*/
private String name;
/**
* 库存数量
*/
private Long stockNum;
}// 加锁 - 此处等同于分布式锁
ReentrantLock lock = new ReentrantLock();
// 实现方法
@SneakyThrows
@Override
@Transactional
public void updateById(Long id) {
lock.lock();
try {
// 查询物料库存，扣减，然后更新库存
MaterialStock materialStock = materialStockMapper.selectById(id);
Long stockNum = materialStock.getStockNum();
if (materialStock.getStockNum() <= 0) {
log.info("库存不足");
return;
}
materialStock.setStockNum(stockNum - 1);
materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());
// 其他处理，耗时 500ms
TimeUnit.MILLISECONDS.sleep(500);
}finally {
// 释放锁
lock.unlock();
}
}// 单元测试
public void test3(){
for (int i = 0; i < 30; i++) {
new Thread(() -> customExecutorService.updateById(1L)).start();
}
}接下来，模仿并发下的场景，设置20个库存，使用30个线程同步进行扣减，查看库存扣减的情况
可以发现，库存中出现了少扣的情况，按照我们预想的执行，流程上应该是【加锁 -> 查询库存 -> 扣减库存 -> 更新库存 -> 释放锁】，数据上【线程数 30 - 库存数 20 = 剩余库存数 10】
现在看来，锁应该是失效了，那这是怎么回事呢？
代码分析
首先分析，一定是在【查询库存】的环节异常，将上次扣减的库存查询出来，那出现这种情况只有两种可能性，一种是【加锁】环节没有生效，一种就是【更新库存】没有执行成功，目前代码上加锁逻辑没有任何问题，那么出现问题的就只能是【更新库存】了，通过对更新库存的操作进行断点，我们查看库存的扣减情况，下面过程中发现当【更新库存 -> 释放锁】的步骤执行完，数据库中的数据并没有更新，事务并没有提交。
上面场景中，上一次线程库存数量已更新为18个，但是当前线程读取到的还是19个，且对此库存进行扣减，初步分析为上一个事务没有提交，当前线程就已经读取库存了。
说到这，了解事务实现原理的童鞋可能已经分析出来了，事务底层是通过aop实现，aop底层又是动态代理对象实现，此时上一个线程update方法执行结束，锁已经释放了，但是整个service方法还没有执行结束，后置处理中的事务还没有提交，其他线程此时开始加锁读取库存数量，就导致了此问题的产生。
解决方式
解决方式就比较多了，根据不同业务复杂度，可做不同的处理
1、业务场景简单的情况，将锁直接提到上层，调用带事务的service即可
public void test3(){
// 加锁
ReentrantLock lock = new ReentrantLock();
for (int i = 0; i < 30; i++) {
new Thread(() -> {
lock.lock();
try {
customExecutorService.updateById(1L);
}finally {
// 释放锁
lock.unlock();
}
}).start();
}
}查看数据，发现正常扣减了
2、业务场景复杂的情况，要考虑锁的力度，根据业务逻辑拆分接口，可将逻辑校验都提到代码最前方，将库存校验留到校验的最后，且与更新库存进行绑定，进行加锁处理，流程如下
// 加锁 - 此处等同于分布式锁
ReentrantLock lock = new ReentrantLock();
@Override
public void updateById(Long id) {
try {
// 其他逻辑处理...
lock.lock();
// 处理事务
stockNum(id);
}finally {
// 释放锁
lock.unlock();
}
}
@SneakyThrows
@Transactional
void stockNum(Long id) {
// 查询物料库存，扣减，然后更新库存
MaterialStock materialStock = materialStockMapper.selectById(id);
Long stockNum = materialStock.getStockNum();
if (materialStock.getStockNum() <= 0) {
log.info("库存不足");
return;
}
materialStock.setStockNum(stockNum - 1);
materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());
// 其他IO处理，耗时 500ms
TimeUnit.MILLISECONDS.sleep(500);
}总结
解决这个问题的本质，就是不要将锁，放到被事务方法中，同时也要思考如果是其他aop切面或者自定义代理了方法会不会有影响。
往往开发的过程中使用的技术体系与底层的实现原理息息相关，掌握原理带动大脑思考