高并发写测试悲观锁，乐观锁

源码地址
有纰漏，错误，欢迎指正，谢谢

JMeter测试工具

• 需要创建一个心的工程；
• 添加一个线程组—这里面设置秒级并发数；
• 添加一个请求—这里设置压力测试的接口；参数使用:${ }可以从csv文件中获取数据
• 请求头管理—添加需要修改的请求头信息；
• CSV文件—可以将请求的参数，以变量的形式，从csv文件中获取，模拟多种请求数据；

具体怎么用，百度

测试场景

• 测试场景为：请求对应商品，减少对应库存；

• 并发量：秒级1w请求；

• 声明：本次测试，请求操作失败，直接丢弃，没有采取补救措施，单纯测试两种锁的写性能；

不加锁

Controller就不写了，但是要测试，需要通过Request测试

Mapper：直接更新stock库存数量

int updateStock(ProductLock lock);

<update id="updateStock" parameterType="com.example.lock.entity.ProductLock">
    update product_lock
    set stock = stock-#{stock,jdbcType=INTEGER}
	where id = #{id,jdbcType=INTEGER}
    AND
    stock > 0
</update>

Service：先查询到商品详情，判断库存是否充足，更新库存数量

@Transactional(rollbackFor = Exception.class)
public int updateStock(ProductLockDto dto) throws Exception{
    int res=0;
    ProductLock entity=productLockMapper.selectByPrimaryKey(dto.getId());
    // 判断：要更新的库存 > 当前库存
    if (entity!=null && entity.getStock().compareTo(dto.getStock())>=0){
        entity.setStock(dto.getStock());
        return productLockMapper.updateStock(entity);
    }
    return res;
}

通过JMeter测试（秒级1w并发量），出现问题：

1. 库存剩余数 > 应该剩余数，存在少卖现象；

乐观锁—版本号

修改表结构：

1. 添加字段：版本号version

修改Mapper：

<update id="updateStock_2" parameterType="com.example.lock.entity.ProductLock">
    update product_lock
    set stock = stock-#{stock,jdbcType=INTEGER},version = version + 1
    where
    id = #{id,jdbcType=INTEGER}
    AND
    version = #{version,jdbcType=INTEGER}
    AND
    stock > 0
</update>

测试

依然秒级并发1w请求测试：（1w个请求，每个请求减少库存数=2）

测试前数据：库存2w，version=0

测试数据后：库存18298，version=851

分析

首先，真正请求通过，并修改了库存的请求数应该等于version的增量；

即：version * 2 = 减少库存数（因为每个version修改，库存减少2）

851 * 2 = 1702 也就等于 20000 - 18298 = 1702 说明：后端数据修改是没有问题的；

但是：version修改次数，可以认为是成功响应请求次数：851个；

1w请求，响应了851个，不太象话；

结论

1. 不存在超卖，少卖的情况；
2. 高并发下，不能响应所有请求，只能响应少部分请求；
3. 因为乐观锁的机制，version字段，判断失败，直接不做操作，导致大部分请求，无法成功；

在高并发写入的情况下，不应该使用乐观锁！，后面悲观锁效果更好

悲观锁—for update

添加Mapper：

<!--悲观锁实现 for update 锁表-->
<select id="selectByIdNegative" parameterType="java.lang.Integer" resultMap="BaseResultMap">
    select
    <include refid="Base_Column_List" />
    from product_lock
    where id = #{id}
    for update
</select>
<update id="updateStock_3" parameterType="com.example.lock.entity.ProductLock">
    update product_lock
    set stock = stock-#{stock,jdbcType=INTEGER},version = version+1
    where
    id = #{id,jdbcType=INTEGER}
    AND
    stock > 0
</update>

Service层：@Transactional注解，保证上面两个方法，是一个事务，才能实现for update 锁表

@Transactional(rollbackFor = Exception.class)
public int updateStock_3(ProductLockDto dto){
    int res =0;
    // select-for update 查询
    ProductLock entity = productLockMapper.selectByIdNegative(dto.getId());
    // 判断version字段，库存是否充足
    if (entity!=null && entity.getStock().compareTo(dto.getStock())>=0){
        entity.setStock(dto.getStock());
        res = productLockMapper.updateStock_3(entity);
    }
    if (res > 0) {
        log.info("减少库存=>{}",dto.getStock());
    }
    return res;
}

测试

依然秒级并发1w请求测试：（1w个请求，每个请求减少库存数=2）

测试前数据：库存2w，version=0

测试数据后：库存356，version=9822

分析

与之前一样：version*2 = 减少库存数（因为每个version修改，库存减少2）

9822 * 2 = 19644 也就等于 20000 - 356 = 19644 说明：后端数据修改是没有问题的；

同样：并没有响应所有的请求，但是从version的修改次数看，

1w请求，响应了9822个请求，失败178个

结论

1. 不存在超卖，少卖的情况；
2. 高并发下，不能响应所有请求，但是响应绝大部分请求；
3. 在写方面，优于乐观锁；