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>
- mapper
public interface StockMapper extends BaseMapper<Stock> { }
- service
@Service public 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(); } }
-
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今天压力测试,发现可以满足数据一致的问题。
-
问题分析:
- 性能很低,并且会随着并发越来越高吞吐量会越来越低(因为线程越多修改失败的就越多,进行自旋的线程也就越多)。
- ABA问题:其实用来判断是否被修改的
version
字段可能已经被其他线程改过了,但是又改了回来,就导致当前线程无法判断出已经被修改,也就是仍然会任务当前可以进行更新。 - 在读写分离(主从)的情况下,可能回导致乐观锁不可靠:进行主从复制需要进行两次网络IO(读取主库、主库相应),两次本地IO(写入本地、从本地读出),在这个过程中可能有些数据已经被更改了。这就导致在进行查询时数据会有一定的延迟性,导致修改失败(或者不应该更改成功)。
4. JVM和MySQL锁总结
- 性能:一条sql锁>悲观锁>JVM锁>乐观锁。
- 在业务场景允许的情况下肯定优先选择一条更新sql自带的默认锁啊。
- 如果是多读少写,争抢不是很激烈的情况下优先选择乐观锁。
- 如果写入的并发量比较高,而且经常出现锁冲突,为了避免出现锁冲突而进行自旋的情况越来越多,优先选择悲观锁。