MyBatis-Plus乐观锁机制详解与实战应用

1. 乐观锁机制的核心价值与应用场景

在并发编程的世界里，数据一致性就像多人同时编辑同一份文档——如果没有合适的协调机制，最终结果往往会出人意料。传统方案是采用数据库悲观锁（如SELECT FOR UPDATE），但这相当于直接把文档锁住不让其他人编辑，虽然安全却严重影响了系统吞吐量。而MyBatis-Plus提供的乐观锁机制，则像Google Docs的协作编辑：每个人都可以自由修改，系统通过版本号比对自动合并冲突。

金融账户余额变更是个典型场景。假设用户A和用户B同时发起提现操作，账户当前余额100元，各自要取50元。没有锁机制时，两个线程都可能读取到100元的初始值，最终余额可能错误地变成50元而非正确的0元。乐观锁通过版本号比对，能让后提交的操作自动失败并提示"数据已被修改"。

2. 实现原理深度解析

2.1 版本号控制的核心逻辑

乐观锁的实现依赖version字段，其工作原理类似CAS(Compare-And-Swap)：

1. 读取数据时获取当前version值（假设为v1）
2. 更新时执行条件：UPDATE table SET money=newValue, version=v1+1 WHERE id=1 AND version=v1
3. 受影响行数为0时说明版本号不匹配，抛出乐观锁异常

这种设计有三大优势：

• 无阻塞：读操作完全不加锁
• 轻量级：仅增加一个整型字段
• 可重试：冲突后可重新读取数据再次执行业务逻辑

2.2 MyBatis-Plus的自动化实现

常规JDBC需要手动拼装version条件，而MyBatis-Plus通过拦截器自动完成：

java复制@Bean
public MybatisPlusInterceptor mybatisPlusInterceptor() {
    MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
    interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
    return interceptor;
}

实体类标注版本字段：

java复制@Version
private Integer version;

执行更新时框架自动：

1. 检查@Version字段是否存在
2. 在WHERE条件追加version=oldVersion
3. 设置新version为oldVersion+1

3. 完整实战示例：电商库存管理

3.1 数据表设计

sql复制CREATE TABLE product (
    id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    stock INT NOT NULL COMMENT '库存量',
    version INT DEFAULT 0 COMMENT '乐观锁版本号'
);

3.2 Java实体类配置

java复制@Data
public class Product {
    private Long id;
    private String name;
    private Integer stock;
    
    @Version
    private Integer version;
}

3.3 库存扣减服务

java复制@Transactional
public boolean reduceStock(Long productId, int quantity) {
    Product product = productMapper.selectById(productId);
    if (product.getStock() < quantity) {
        throw new RuntimeException("库存不足");
    }
    
    product.setStock(product.getStock() - quantity);
    int updated = productMapper.updateById(product);
    if (updated == 0) {
        throw new OptimisticLockException("并发修改冲突");
    }
    return true;
}

4. 生产环境中的进阶技巧

4.1 重试机制设计

乐观锁冲突时应自动重试而非直接报错：

java复制@Retryable(value = OptimisticLockException.class, maxAttempts = 3)
public void purchaseWithRetry(Long productId) {
    // 业务逻辑
}

4.2 版本号溢出处理

当version达到Integer.MAX_VALUE时：

1. 方案一：重置为0（需确保旧version已无残留事务）
2. 方案二：使用BigInteger类型（需修改字段类型）

4.3 与分布式锁配合

高并发场景可结合Redis分布式锁：

1. 先用分布式锁保证短时独占
2. 再通过乐观锁保证数据一致性
3. 最后释放分布式锁

5. 性能对比与压测数据

通过JMeter模拟100并发测试：

关键发现：

• 纯乐观锁的错误率来自冲突放弃
• 3次重试后错误率降为0且仍优于悲观锁
• 实际业务应设置合理的重试次数上限

6. 常见踩坑与解决方案

6.1 版本号未更新的幽灵问题

现象：更新成功但version没变
原因：忘记在实体类加@Version注解
解决：检查实体类字段注解

6.2 批量更新的特殊处理

批量操作需要自定义SQL：

xml复制<update id="updateBatch">
    UPDATE product SET 
    stock = CASE id
        <foreach collection="list" item="item">
            WHEN #{item.id} THEN #{item.stock}
        </foreach>
    END,
    version = CASE id
        <foreach collection="list" item="item">
            WHEN #{item.id} THEN version + 1
        </foreach>
    END
    WHERE id IN
    <foreach collection="list" item="item" open="(" separator="," close=")">
        #{item.id}
    </foreach>
    AND version = CASE id
        <foreach collection="list" item="item">
            WHEN #{item.id} THEN #{item.version}
        </foreach>
    END
</update>

6.3 与逻辑删除的冲突

当启用@TableLogic时，需确保乐观锁条件在前：

sql复制WHERE version=? AND deleted=0

7. 与其他并发控制方案对比

实际项目中，我通常会根据业务特征组合使用：

• 支付核心流程：悲观锁+乐观锁双重校验
• 商品库存：乐观锁+告警阈值
• 秒杀活动：Redis预减库存+乐观锁最终核对