数据库中的乐观锁与悲观锁

数据库的乐观锁与悲观锁

• • 乐观锁
  • 悲观锁

作者： 齐大圣2012
链接： https://blog.csdn.net/qidasheng2012/article/details/83007103
来源： CSDN

引用文本著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

乐观锁

适用场景

乐观锁比较适合并发量不高，并且写操作不频繁的场景.

定义

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

他只有在更新数据的时候才会检查这条数据是否被其他线程更新了(这点与悲观锁一样，悲观锁是在读取数据的时候就加锁了)。如果更新数据时，发现这条数据被其他线程更新了，则此次更新失败。如果数据未被其他线程更新，则更新成功。由于乐观锁没有了锁等待，提高了吞吐量，所以乐观锁适合多读少写的场景。

实现方式

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

UPDATE TABLE 
SET columnA = 1, VERSION = VERSION + 1 
WHERE ID = #{ID} 
AND VERSION = #{oldVersion}

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

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

UPDATE product 
SET rest = rest–#{deduct} 
WHERE
	NAME = 'abc'
	AND rest >= #{deduct}

优点与缺点分析

• 优点
  由于在检测数据冲突时并不依赖数据库本身的锁机制，不会影响请求的性能，当产生并发且并发量较小的时候只有少部分请求会失败。
• 缺点
  需要对表的设计增加额外的字段，增加了数据库的冗余，另外，当应用并发量高的时候，version值在频繁变化，则会导致大量请求失败，影响系统的可用性。

悲观锁

适用场景

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

定义

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

总会认为：每当修改数据时，会有其他线程也会同时修改该数据。所以针对这种情况悲观锁的做法是：读取数据之后就加锁(eg: select…for update)，这样别的线程读取该数据的时候就需要等待当前线程释放锁，获得到锁的线程才能获得该数据的读写权限。从而保证了并发修改数据错误的问题。但是由于阻塞原因，所以导致吞吐量不高。悲观锁更适用于多写少读的情况。

实现方式

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

SELECT * FROM TABLE WHERE ID = 1 FOR UPDATE

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

一个不错的例子

优点与缺点分析

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