商城首页欢迎来到中国正版软件门户

您的位置:首页 >MybatisPlus实现悲观锁 & 乐观锁的项目实践

MybatisPlus实现悲观锁 & 乐观锁的项目实践

  发布于2026-08-06 阅读(0)

扫一扫,手机访问

MyBatis-Plus 对乐观锁的支持的确很到位,内置了插件,用起来非常顺手。但悲观锁就没那么方便了——它没有专门的封装,得靠底层 SQL 或者原生 MyBatis 的方式来实现。下面把这两种锁的实践方法掰开揉碎了讲清楚。

MybatisPlus实现悲观锁 & 乐观锁的项目实践

一、乐观锁(Optimistic Lock)

乐观锁的核心思路其实很简单:更新时先检查版本号,版本号对得上才更新,同时把版本号+1。MyBatis-Plus 专门为此提供了插件,省去了不少重复劳动。

1. 实体类加@Version注解

@Data
public class Product {
    private Long id;
    private String name;
    private Integer price;
    
    @Version  // 乐观锁版本号字段
    private Integer version;
}

2. 配置乐观锁拦截器

@Configuration
public class MybatisPlusConfig {
    
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        // 添加乐观锁拦截器
        interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
        return interceptor;
    }
}

3. 使用方式

// 1. 先查询出实体(version 会被查出来)
Product product = productService.getById(1L);

// 2. 修改数据
product.setPrice(product.getPrice() + 100);

// 3. 执行更新(MP 会自动在 WHERE 条件中加上 version = ?)
// 生成的 SQL 类似:
// UPDATE product SET price=?, version=version+1 WHERE id=? AND version=?
boolean success = productService.updateById(product);

4. 注意事项

注意点说明
version 字段类型支持 int、Integer、long、Long、Date、Timestamp
必须查后更新updateById(entity) 才会生效,直接 new 一个对象更新不会触发乐观锁
自增逻辑框架自动 version + 1,无需手动设置
更新失败如果返回 false,说明数据已被他人修改,需要业务上重试或抛异常

5. 批量更新也支持

// 批量更新时,每个实体的 version 都会参与 WHERE 条件
productService.updateBatchById(productList);

二、悲观锁(Pessimistic Lock)

悲观锁就完全是另一回事了。MyBatis-Plus 没有提供专门的悲观锁插件,因为悲观锁本质上是数据库层面的机制,得靠 SQL 的 FOR UPDATE 来实现。既然框架没包办,那我们就自己动手。

方式一:手写 SQL(推荐)

在 Mapper 中直接用 @Select 注解写带 FOR UPDATE 的 SQL,既清晰又可控:

public interface ProductMapper extends BaseMapper {
    
    @Select("SELECT * FROM product WHERE id = #{id} FOR UPDATE")
    Product selectByIdForUpdate(Long id);
}

Service 层调用时,记得一定要加 @Transactional——FOR UPDATE 依赖事务才能生效:

@Service
public class ProductServiceImpl extends ServiceImpl 
    implements ProductService {
    
    @Transactional  // 必须在事务中,FOR UPDATE 才有效
    public void deductStock(Long id) {
        // 1. 加锁查询
        Product product = baseMapper.selectByIdForUpdate(id);
        
        // 2. 执行业务逻辑
        if (product.getStock() > 0) {
            product.setStock(product.getStock() - 1);
            updateById(product);
        }
    }
}

方式二:用 Wrapper 拼接(不推荐,容易出问题)

// 不推荐,因为 FOR UPDATE 是写在 SQL 末尾的,QueryWrapper 不好控制位置
// 而且 MP 的 selectOne 等方法不支持直接加 FOR UPDATE

方式三:XML 方式


三、对比与选型

特性乐观锁悲观锁
MP 支持✅ 原生插件支持❌ 需手写 SQL
实现机制版本号控制SELECT ... FOR UPDATE
性能高(无锁等待)低(有锁竞争、阻塞)
适用场景读多写少、冲突概率低写多读少、冲突概率高、强一致性
失败处理更新失败需重试排队等待,不会失败
事务要求非必须必须在事务中

四、最佳实践建议

优先用乐观锁:绝大多数互联网场景读多写少,乐观锁性能更好,而且 MP 支持得相当完善,几乎零成本接入。

悲观锁用于强一致性场景:比如库存扣减、金融转账这类高并发写操作,冲突概率高,宁可让线程排队也要保证数据绝对正确,这时候悲观锁更靠谱。

乐观锁失败重试

// 简单的重试机制
public boolean updateWithRetry(Product product, int maxRetries) {
    for (int i = 0; i < maxRetries; i++) {
        if (productService.updateById(product)) {
            return true;
        }
        // 重新查询最新数据
        product = productService.getById(product.getId());
    }
    throw new RuntimeException("更新失败,请重试");
}
本文转载于:https://www.jb51.net/program/36867988n.htm 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

热门关注