浅谈数据库乐观锁和悲观锁（乐观锁与悲观锁的应用场景）

在单实例JVM中，常见的处理并发问题的方法有很多，比如synchronized关键字进行访问控制、volatile关键字、ReentrantLock等常用方法。但是在分布式环境中，上述方法却不能在跨jvm场景中用于处理并发问题，当业务场景需要对分布式环境中的并发问题进行处理时，需要使用其他方式来实现，如数据库锁机制、缓存数据库如redis以及zookeeper分布式锁等。

本文主要介绍数据库中常用的乐观锁和悲观锁的实现以及优缺点。

数据库乐观锁：

定义：顾名思义，系统认为数据的更新在大多数情况下是不会产生冲突的，只在数据库更新操作提交的时候才对数据作冲突检测。如果检测的结果出现了与预期数据不一致的情况，则返回失败信息。

实现方式：

1. 借助数据库表增加一个版本号的字段version，每次更新一行记录，都使得该行版本号加一，开始更新之前先获取version的值，更新提交的时候带上之前获取的version值与当前version值作比较，如果不相等则说明version值发生了变化则检测到了并发冲突，本次操作执行失败，如果相等则操作执行成功。

例如：update table set columnA = 1,version=version+1 where id=#{id} and version = #{oldVersion}

2. 借助行更新时间时间戳，检测方法则与方式1相似，即更新操作执行前先获取记录当前的更新时间，在提交更新时，检测当前更新时间是否与更新开始时获取的更新时间时间戳相等。

3. 前面2种方式都是提交的时候检测版本有没有改变，只要有变化都会失败，而有一类场景当字段只需要满足一个区间范围并不关心是否有数据更新冲突，且本身进行更新并且作为判断条件时，可不借助其他字段，对字段本身作判断即可。例如一个较常见的场景：库存的扣减，只要扣减后的值大于等于零即可。例如：update product set rest = rest– #{deduct} where name = ‘abc’ and rest >= #{deduct

优点与缺点分析，优点比较明显，由于在检测数据冲突时并不依赖数据库本身的锁机制，不会影响请求的性能，当产生并发且并发量较小的时候只有少部分请求会失败。缺点则是，一需要对表的设计增加额外的字段，增加了数据库的冗余，另外，当应用并发量高的时候，version值在频繁变化，则会导致大量请求失败，影响系统的可用性。我们通过上述sql语句还可以看到，数据库锁都是作用于同一行数据记录上，这就导致一个明显的缺点，在一些特殊场景，如大促、秒杀等活动开展的时候，大量的请求同时请求同一条记录的行锁，会对数据库产生很大的写压力。所以综合数据库乐观锁的优缺点，乐观锁比较适合并发量不高，并且写操作不频繁的场景。

数据库悲观锁：

定义：根据命名即对数据进行操作更新时，对操作持悲观保守的态度，认为产生数据冲突的可能性很大，需要先对请求的数据加锁再进行相关的操作。

实现方式：通过数据库锁机制实现，即对查询语句添加for update关键字。

如下sql语句 select * from table where id = 1 for update 当一个请求A开启事务并执行此sql同时未提交事务时，另一个线程B发起请求，此时B将阻塞在加了锁的查询语句上，直到A请求的事务提交或者回滚，B才会继续执行，保证了访问的隔离性。

悲观锁优缺点分析，优点是每一次行数据的访问都是独占的，只有当正在访问该行数据的请求事务提交以后，其他请求才能依次访问该数据，否则将阻塞等待锁的获取。悲观锁可以严格保证数据访问的安全，但是缺点也明显，即每次请求都会额外产生加锁的开销且未获取到锁的请求将会阻塞等待锁的获取，在高并发环境下，容易造成大量请求阻塞，影响系统可用性。另外，悲观锁使用不当还可能产生死锁的情况。

我们来看如下情况，以商品表、用户商品列表为例：

系统出现了2个业务操作，操作A先查询商品表并加锁，根据查询的结果作更新用户商品列表状态字段的操作，sql为 select * from product where id = 10 for update;update user_product set status = 2 where user_id = 10001;。业务操作B先查询用户商品表并加锁，根据查询结果更新商品表剩余数量的操作,sql为select * from user_product where user_id = 10001 for update；update product set rest = rest – 1 where id = 10。

我们看一下产生死锁的过程：A业务操作开启事务，获取product表id=10的行锁，B业务操作接着开启事务并获取user_product表user_id为10001记录的行锁，A继续执行更新操作，需要等待获取user_product表user_id为10001的行锁进入阻塞状态如下图1所示，B继续执行更新操作需要等待获取product表id=10的行锁。此时我们可以发现数据库的状态为A等待的锁被B占住，而B等待的锁被A所占住，双方事务都未提交都在等待对方释放锁，进入一个死循环状态。

如图2所示，数据库（mysql5.7）检测到产生了死锁，自动回滚了B操作的事务，释放了锁。虽然常见数据库如oracle或者mysql都有死锁检测机制，出现死锁数据库会自动回滚一个事务，但是也会造成系统的可用性和稳定性受到影响，我们应该避免在实际应用场景中出现死锁的情况，如上例所示，可以考虑把一个操作改为乐观锁实现或者改变锁的获取顺序使得2个操作都是先获取同一个锁再获取另外一个锁，以此避免死锁的发生。综合数据库悲观锁的特点，在

图1 A操作执行其update操作时等待锁的获取

图2 B操作执行update时，数据库检测到死锁则回滚

并发量较小、又需要独占读取结果并依赖读取的结果进行判断的业务场景比较适合使用悲观锁。