mysql行锁和死锁检测高并发使用JVM锁和MySQL锁解决数据不一致问题

导读1.引入并发问题1.1项目搭建这里以一个最基础的库存问题引入：在高并发下下单会造成库存数据异常情况。数据表：就一个最基础的库存表和一个基础的数据。2.新建S....1. 引入并发问题1.1 项目搭建

这里以一个最基础的库存问题引入：在高并发下下单会造成库存数据异常情况。

数据表：就一个最基础的库存表和一个基础的数据。

2. 新建SpringBoot2.7.3项目并引入相关依赖：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

1. mapper

public interface StockMapper extends BaseMapper<Stock> { }

1. service

@Servicepublic class StockServiceImpl implements StockService { @Resource private StockMapper stockMapper; @Override public Integer deStock() { Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>() .eq("product_code", "1001")); if (!Objects.isNull(stock) && stock.getCount() > 0){ stock.setCount(stock.getCount() -1); stockMapper.updateById(stock); } return stockMapper.selectById(stock.getId()).getCount(); }}

2.controller

@RestController@RequestMapping("/stock")public class StockController { @Resource private StockService stockService; @GetMapping public String deStock(){ return "库存剩余：" stockService.deStock(); }}

1.2 使用Jmeter进行测试

• 使用十个线程各发送十各请求，也就是共100各请求，这里设置数据中也刚好有100库存。

• 请求之后可以发现：请求的数量与数据库中的库存剩余对应不上，这个值应该处于于0 - 90 之间，每个用户至少有一个请求会进去。

2. JVM锁解决

这里直接不测试了，肯定可以解决。

修改service减库存方法：

synchronized

@Override public synchronized Integer deStock() { Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>() .eq("product_code", "1001")); if (!Objects.isNull(stock) && stock.getCount() > 0){ stock.setCount(stock.getCount() -1); stockMapper.updateById(stock); } return stockMapper.selectById(stock.getId()).getCount(); }

ReentrantLock 显示锁

@Override public Integer deStock() { ReentrantLock reentrantLock = new ReentrantLock(); try { reentrantLock.lock(); Stock stock = stockMapper.selectOne(new QueryWrapper<Stock>() .eq("product_code", "1001")); if (!Objects.isNull(stock) && stock.getCount() > 0){ stock.setCount(stock.getCount() -1); stockMapper.updateById(stock); } return stockMapper.selectById(stock.getId()).getCount(); }finally { reentrantLock.unlock(); } }

JVM锁缺陷：

• 只有是单例的 stockService 对象下才能保证锁进行成功，在多例情况下每个对象都拥有自己的锁，不需要等待其他线程释放锁就可以执行。
• 在开启spring事务的情况下锁也可能（有一定几率）失效：由于spring的锁是使用AOP的方式来进行增强，如果同时A、B两个用户分别发送两个请求事务也会开启两个，但是由于只能一个用户（线程）才能够获得锁，完成之后才会释放锁；此时A用户的事务并没有提交，但是B用户已经可以获取当前方法的锁，那么就会造成一个数据不一致的问题，B获取的库存是A提交前的数量。如图：
• 当然可以通过设置Spring事务中的隔离级别为读未提交来解决，但这种隔离级别就完全不满足系统需求了。
• 集群模式下：在不同的服务中的 stockService 肯定也不是一个相同的对象，存在与第一中失效方式相似的问题。

总结来说：上诉缺陷除了能避免使用多例模式，其他两种在系统构建上是无法进行取代的，因此需要使用其他的方式来进行并发数据的处理。3. MySQL实现锁3.1 MySQL默认锁

使用MySQL中自带的锁去解决：MySQL在执行更、删、改操作时会自动对当前语句加锁，也就是说我们只要能够使用一条sql来实现当前功能就可以避免数据问题。

• 新增mapper接口方法：

@Update("update db_stock set count = count - #{count} " "where product_code = #{productCode} and count >= #{count}") Integer deduct(@Param("productCode") String productCode, @Param("count") Integer count);

修改service实现类方法：

@Override public Integer deStock() { return stockMapper.deduct("1001", 1); }

• 使用Jmeter来测试，可以发现不会出现数据异常问题。
• 解决：很明显的可以看出一条sql中携带的锁可以完美的解决上方JVM锁失效的问题，但是真的那么？
• 发现问题：一条sql无法实现在复杂情况下的操作，例如：如果一条商品code有多个仓库，就无法实现了。同样的无法记录库存在进行下单前后的状态变化。锁的粒度：通过分析可以看出，当前sql是一个表级锁，即当前sql在事务为提交之前，其他的io操作都无法执行。

3.2 MySQL悲观锁

• 使用 select ... for update ，可以对当前查询出的数据加上行级锁，即其他事务无法对已经查询出的数据进行修改删除等操作。
• 但是想要改为行级锁就必须满足以下要求：
• 查询或者更新条件必须是索引字段；
• 查询或者更新条件必须是一个具体值（不能使索引失效）；
• 新增 mapper 中方法：

@Select("select * from db_stock where product_code = #{productCode} for update") List<Stock> selectStockForUpdate(String productCode);

改造 service 中方法：

@Transactional @Override public Integer deStock() { List<Stock> stocks = stockMapper.selectStockForUpdate("1001"); if (Objects.isNull(stocks) || stocks.isEmpty()){ return -1; } // 假设存在多仓库情况，默认扣减第一个仓库 Stock stock = stocks.get(0); if (!Objects.isNull(stock) && stock.getCount() >= 1){ stock.setCount(stock.getCount() - 1); } return stockMapper.updateById(stock); }

• 使用Jmeter测试，可以看出悲观锁也可以实现数据异常的问题。
• 优缺点：效率比JVM锁高，但是比一条sql低；可能存在死锁问题：需要保证对多条数据加锁时顺序一致；库存操作要统一：要么都 select ... for update ，要么都 select ，一个有锁一个没有锁指定会出现数据冲突问题。

3.3 MySQL乐观锁

乐观锁：默认对IO属性操作不加锁，在执行完毕对数据中的版本号或者其他属性进行判断，确定当前数据执行前后是否被其他的事务更改。也就是CAS思想。

CAS：Compare and Swap，比较并交换，其实就是有用一个属性，在更新后判断当前属性是否有变化，有变化就放弃更改，无变化就更改。

• 更改成功
• 放弃更改

• 修改数据库表：新增版本号字段。每次更改时将version进行加一。

修改 service 方法

@Override public Integer deStock() { List<Stock> stocks = stockMapper.selectList( new QueryWrapper<Stock>() .eq("product_code", "1001")); if (Objects.isNull(stocks) || stocks.isEmpty()){ return -1; } // 假设存在多仓库情况，默认扣减第一个仓库 Stock stock = stocks.get(0); Integer version = 0; if (!Objects.isNull(stock) && stock.getCount() >= 1){ version = stock.getVersion(); stock.setCount(stock.getCount() - 1); stock.setVersion(version 1); } QueryWrapper<Stock> queryWrapper = new QueryWrapper<>(); queryWrapper .eq("id", stock.getId()) .eq("version", version); int update = stockMapper.update(stock, queryWrapper); // 更新失败递归重试 if (update == 0){ try { // 避免一直重试导致栈内存溢出 Thread.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); } return deStock(); } return update; }

• 通过Jmeter今天压力测试，发现可以满足数据一致的问题。
• 问题分析：

version

4. JVM和MySQL锁总结

• 性能：一条sql锁>悲观锁>JVM锁>乐观锁。
• 在业务场景允许的情况下肯定优先选择一条更新sql自带的 默认锁 啊。
• 如果是多读少写，争抢不是很激烈的情况下优先选择 乐观锁 。
• 如果写入的并发量比较高，而且经常出现锁冲突，为了避免出现锁冲突而进行自旋的情况越来越多，优先选择 悲观锁 。

,