浅谈面试中常提到的乐观锁与悲观锁

首先来看一下什么是锁？

在并发环境下，会出现多个线程对同一个资源进行争抢的情况，假设A线程对资源正在进行修改，此时B线程此时又对资源进行了修改，这就可能会导致数据不一致的问题。为了解决这个问题，很多编程语言引入了锁机制，通过一种抽象的“锁”来对资源进行锁定，当一个线程持有“锁”的时候，其他线程必须等待“锁”，我认为这本质上就是在临界资源上对线程进行一种串行化。

锁的一种宏观分类方式是悲观锁和乐观锁。悲观锁与乐观锁并不是特指某个锁，而是在并发情况下的两种不同策略。

一、乐观锁（Optimistic Lock）

1、概念

乐观锁：从字面意思看，就是十分乐观的。因为它总是认为不会出现问题，无论干什么都不去上锁~，说白就是每次去拿数据的时候都认为别人不会修改。如果出现了问题，再次更新值测试。这里使用了version字段。

也就是每次更新的时候同时维护一个version字段

2、乐观锁实现的方式

• 取出记录时，获取当前的version
• 更新时，带上这个version
• 执行更新时，set version = newVersion where version = oldVersion
• 如果version不对，就更新失败

乐观锁：1：先查询，获得版本号 version =1

-- A 线程
update user set name = "陌溪", version = version + 1 
where id = 2 and version = 1

-- B 线程抢先完成，这个时候Version = 2，导致A修改失败
update user set name = "陌溪", version = version + 1 
where id = 2 and version = 1

MybatisPlus使用乐观锁

首先需要在数据库增加version字典，默认为1

然后在实体类增加对应的字段 

// 乐观锁Version注解
@Version
private Integer version;

注册组件，在MybatisPlusConfig中配置

// 注册乐观锁
@Bean
public OptimisticLockerInterceptor optimisticLockerInterceptor() {
	return new OptimisticLockerInterceptor();
}

二、悲观锁（Pessimistic Lock）

从字面意思上看，就是十分悲观的意思。因为它总是认为什么时候都会出现问题，无论什么操作都会上锁，再次操作。说白了就是每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿数据就被挡住，直到悲观锁被释放。

三、乐观与悲观

假设现在有多个线程想要操作同一个资源对象，很多人的第一反应就是使用互斥锁。但互斥锁的同步方式是悲观的，什么是“悲观”呢?简单来说，就是操作系统将会悲观地认为，如果不严格同步线程调用，那么一定会产生异常，所以互斥锁将会锁定资源，只供一个线程调用，而阻塞其他线程，让其他线程等待，因此，这种同步机制也叫做“悲观锁”。

但悲观锁不是在所有情况下都适用，比如在一些情况下，同步代码块执行的耗时远远小于线程切换的耗时，这样就很不划算。程序员们可能更加希望一些场景下，能够在用户态中对线程的切换进行管理，这样效率更高。所以，我们不想让操作系统那么“悲观，每次都使用同步原语对共享资源进行锁定，而是希望让线程反复“乐观”地去尝试获取共享资源，如果发现空闲，那么使用，如果被占用，那么继续“乐观”地重试。

四、在事物中

悲观锁阻塞事务，乐观锁回滚重试，它们各有优缺点，不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。