一段关于悲观锁和乐观锁的简述

2015-09-22 10:12:29   作者：MangoCool   来源：网络收集

谈到悲观锁（Pessimistic Locking）和乐观锁（Optimistic Locking），就必须聊到数据库的并发问题，并发访问一直是应用程序开发者需要面对的问题之一，一个好的解决方案不仅可以提供高的可靠性还能给应用程序的性能带来提升。

并发：在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

简单描述：

1、悲观锁：

正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

2、乐观锁：

其实不是锁，是一种机制。它指的是对数据被外界修改持开明态度，只有在数据提交（Commit）时，才将数据锁定。

如何实现：

1、悲观锁：

悲观锁的，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

2、乐观锁：

乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

基本示例：

1、悲观锁：

张三和李四刚好同时要修改一个文件，张三先读到文件，这时将此文件锁住，李四就无法再读取和修改，直到张三修改完成并提交，将锁释放了，李四才可以进行读取并修改文件。

2、乐观锁：

假设数据库中帐户信息表中有一个 version 字段，当前值为1；而当前帐户余额字段 balance 为 $100 。
(1)、操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
(2)、在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20（ $100-$20 ）。
(3)、操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
(4)、操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

总结对比：

悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受；

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，由于乐观锁机制是在我们的系统中实现，来自外部系统的更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。

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

标签： 乐观锁 悲观锁 Optimistic Locking Pessimistic Locking 数据库

分享：

上一篇Executor线程池详解

下一篇JS计算宝宝出生后的年龄，两种表示方式，精确到秒哦