安吉网站开发,网站备案需要收费么,ccd设计公司很厉害吗,家政公司管理系统1 悲观锁和乐观锁场景和介绍
乐观锁和悲观锁是在并发编程中用于处理并发访问和资源竞争的两种不同的锁机制!!
1.1 悲观锁#xff1a;
悲观锁的基本思想是#xff0c;在整个数据访问过程中#xff0c;将共享资源锁定#xff0c;以确保其他线程或进程不能同时访问和修改该…1 悲观锁和乐观锁场景和介绍
乐观锁和悲观锁是在并发编程中用于处理并发访问和资源竞争的两种不同的锁机制!!
1.1 悲观锁
悲观锁的基本思想是在整个数据访问过程中将共享资源锁定以确保其他线程或进程不能同时访问和修改该资源。悲观锁的核心思想是先保护再修改。在悲观锁的应用中线程在访问共享资源之前会获取到锁并在整个操作过程中保持锁的状态阻塞其他线程的访问。只有当前线程完成操作后才会释放锁让其他线程继续操作资源。这种锁机制可以确保资源独占性和数据的一致性但是在高并发环境下悲观锁的效率相对较低。
1.2 乐观锁
乐观锁的基本思想是认为并发冲突的概率较低因此不需要提前加锁而是在数据更新阶段进行冲突检测和处理。乐观锁的核心思想是先修改后校验。在乐观锁的应用中线程在读取共享资源时不会加锁而是记录特定的版本信息。当线程准备更新资源时会先检查该资源的版本信息是否与之前读取的版本信息一致如果一致则执行更新操作否则说明有其他线程修改了该资源需要进行相应的冲突处理。乐观锁通过避免加锁操作提高了系统的并发性能和吞吐量但是在并发冲突较为频繁的情况下乐观锁会导致较多的冲突处理和重试操作。
理解点: 悲观锁和乐观锁是两种解决并发数据问题的思路,不是具体技术!!!
1.3 具体技术和方案:
乐观锁实现方案和技术 版本号/时间戳为数据添加一个版本号或时间戳字段每次更新数据时比较当前版本号或时间戳与期望值是否一致若一致则更新成功否则表示数据已被修改需要进行冲突处理。CASCompare-and-Swap使用原子操作比较当前值与旧值是否一致若一致则进行更新操作否则重新尝试。无锁数据结构采用无锁数据结构如无锁队列、无锁哈希表等通过使用原子操作实现并发安全。 悲观锁实现方案和技术 锁机制使用传统的锁机制如互斥锁Mutex Lock或读写锁Read-Write Lock来保证对共享资源的独占访问。数据库锁在数据库层面使用行级锁或表级锁来控制并发访问。信号量Semaphore使用信号量来限制对资源的并发访问。
2. 乐观锁实现
2.1 版本号乐观锁技术的实现流程:
每条数据添加一个版本号字段version取出记录时获取当前 version更新时检查获取版本号是不是数据库当前最新版本号如果是[证明没有人修改数据], 执行更新, set 数据更新 , version version 1 如果 version 不对[证明有人已经修改了]我们现在的其他记录就是失效数据!就更新失败
2.2 使用mybatis-plus数据使用乐观锁 添加版本号更新插件 Beanpublic MybatisPlusInterceptor mybatisPlusInterceptor() {MybatisPlusInterceptor interceptor new MybatisPlusInterceptor();interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());return interceptor;}乐观锁字段添加Version注解 注意: 数据库也需要添加version字段 ALTER TABLE USER ADD VERSION INT DEFAULT 1 ; # int 类型 乐观锁字段支持的数据类型只有:int,Integer,long,Long,Date,Timestamp,LocalDateTime仅支持 updateById(id) 与 update(entity, wrapper) 方法 Version
private Integer version;2.3 测试
//演示乐观锁生效场景
Test
public void testQuick7(){//步骤1: 先查询,在更新 获取version数据//同时查询两条,但是version唯一,最后更新的失败User user userMapper.selectById(5);User user1 userMapper.selectById(5);user.setAge(20);user1.setAge(30);userMapper.updateById(user);//乐观锁生效,失败!userMapper.updateById(user1);
}上述案例的操作流程为
user和user1都先进行查询操作这一步也获取到了versionuser对age进行了修改此时数据库的version已经得到了更新user1在随后的修改时会检查自己获得的version与目前数据库中的version是否一致。此时发现并不一致因为user对数据库进行了修改。因此user1的修改操作失败。
