夢みてひらひら 私のなかのロマンティック
DML编程控制
实际开发中往往存在多线程并发操作数据库，针对此问题提出了乐观锁和悲观锁的概念
乐观锁&悲观锁
乐观锁 (Optimistic Locking)：
乐观锁的核心思想是“先操作，再检查冲突”。它假设在大多数情况下，数据不会被多个线程或事务同时修改，因此在读取数据时不会加锁。只有在提交更新时，才会检查数据是否被其他线程修改过。如果检测到冲突，则更新失败，通常需要重试或回滚操作。
悲观锁 (Pessimistic Locking)：
悲观锁的核心思想是“先加锁，再操作”。它假设在并发环境中，数据冲突是不可避免的，因此在访问数据时立即加锁，确保同一时间只有一个线程或事务能够修改数据。直到操作完成并释放锁后，其他线程才能访问。
乐观锁和悲观锁对比：
适用场景：
乐观锁适用于读多写少、并发冲突少的场景，例如电商秒杀、分布式系统等高并发场景
悲观锁适用于写多读少、并发冲突多的场景。例如金融交易、订单支付等不允许出现数据冲突或不一致的场景性能对比
乐观锁无锁读取，读取性能高；由于写操作可能失败需重试，写密集时性能下降
悲观锁读取时需加锁，性能开销大；高并发下容易阻塞，吞吐量低
乐观锁实现机制
在数据表中增加一个版本号字段（如version），每次更新数据时，会检查当前版本号是否与读取时的版本号一致。如果一致，则更新并递增版本号；否则，更新失败，需要重试。
核心步骤如下：
①要在对应的数据实体类中添加
version属性，并且添加@Version标注
②在拦截器中添加乐观锁拦截器
③执行修改操作时，每次查询修改的数据获取version属性，然后根据version属性执行操作
具体代码如下：
//src/main/java/org/example/Config/MpConfig.java 拦截器设置
@Configuration
public class MpConfig {@Beanpublic MybatisPlusInterceptor mybatisPlusInterceptor() {MybatisPlusInterceptor myinterceptor = new MybatisPlusInterceptor();myinterceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); //乐观锁插件return myinterceptor;}
}// src/main/java/org/example/pojo/EmpTestData.java 实体类
@Data
@AllArgsConstructor
@NoArgsConstructor
@TableName("emptest")
public class EmpTestData {int id;String name;@TableLogicint deleted;@Versionint version;
}// src/test/java/org/example/MyBatisTestApplicationTests.java@SpringBootTest
class MyBatisTestApplicationTests {@Testvoid testUpdate(){EmpTestData empTestData = empTestDao.selectById(4);empTestData.setName("JokerFive");empTestDao.updateById(empTestData);}
}
效果如下：
修改前数据库表如下：
修改后：
如果存在多次并发修改的话
@SpringBootTest
class MyBatisTestApplicationTests {@Testvoid testUpdate(){EmpTestData empTestData = empTestDao.selectById(4);EmpTestData empTestData2 = empTestDao.selectById(4);empTestData.setName("JokerFive3");empTestData2.setName("JokerFive4");empTestDao.updateById(empTestData);empTestDao.updateById(empTestData2);}
}
那么效果如下：
可以看到只有第一次的修改生效，第二次由于version不匹配无法提交修改，需要重新操作
