详解 BAT 面试中常考的数据库「锁」问题

在数据库的操作中，有可能会出现数据不一致的问题，一个常见的例子如下：

1. A 给 B 转账 100 元
2. A 的账户减少 100 元
3. B 的账户增加 100 元
4. 完成

若在 2 后的一瞬间进行查看，可以发现 A 的账户减少了 100 元但是 B 的账户余额却没有任何变化（当然，这种情况只发生在对应课本的对应章节里），数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性，例如：

现有两处火车票售票点，同时读取某一趟列车车票数据库中车票余额为 X。两处售票点同时卖出一张车票，同时修改余额为 X-1 写回数据库，这样就造成了实际卖出两张火车票而数据库中的记录却只少了一张。

产生这种情况的原因是因为两个事务读入同一数据并同时修改，其中一个事务提交的结果破坏了另一个事务提交的结果，导致其数据的修改被丢失，破坏了事务的隔离性，其他类似的问题还有：

• 丢失或覆盖更新
• 读脏数据
• 非重复读

并发控制要解决的就是这类问题，在公司的面试中关于数据库的环节往往会有这样的问题：如何解决数据库并发带来的不一致性？锁分为哪几类，分别有什么作用？

什么是锁

为了面对由于并发引来的一些问题，在数据库中有「锁」的概念，即当并发事务同时访问一个资源时，有可能导致数据不一致，因此需要一种机制来将数据访问顺序化，以保证数据库数据的一致性，为了通俗地理解锁的概念，以写作作为比喻：

在一个博客平台上写作和发布时，对于已经发布的文章可以允许所有人同时阅读，而对于正在修改的文章，我们并不希望读者看到我们修改的过程，同时也不希望其他的编辑对我们正在修改的文章有任何的修改，所以我们将文章暂时地下线进行修改，修改完成后再次上线到页面上。

数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性需要遵从 ACID 特性：

• 原子性（Atomicity）

一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。

• 一致性（Consistency）

在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

• 隔离性（Isolation）

数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

• 持久性（Durability）

事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

数据库中的锁

我们需要知道的是，数据库对于数据的操作无非两种类型，读和写，针对这个特点，目前有两种数据库的锁，乐观锁和悲观锁，乐观锁和悲观锁的区别在于 是否认为并发问题一定会存在。

当然，除了乐观锁和悲观锁两个被大家广泛讨论的类型以外，还有以下名称的锁，有兴趣的读者可以自行进行探索：

• 按锁的粒度划分（即，每次上锁的对象是表，行还是页）：表级锁，行级锁，页级锁
• 按锁的级别划分：共享锁、排他锁
• 按加锁方式分：自动锁（存储引擎自行根据需要施加的锁）、显式锁（用户手动请求的锁）
• 按操作划分：DML锁（对数据进行操作的锁)、DDL锁（对表结构进行变更的锁）
• 最后按使用方式划分：悲观锁、乐观锁

悲观锁

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法，即为悲观的思想，认为并发问题总会出现，所以每次一个事务读取某一条记录后，就会把这条记录锁住，这样其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。

悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

我们在数据库课程中所学习到的共享锁（S 锁）和排他锁（X 锁）即为悲观锁。

共享锁

共享锁(S)表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。（对于写作来说就是，如果文章处于「已发布」的状态，则所有人都可以同时看。）

在数据库中使用方法：

SELECT ... LOCK IN SHARE MODE;

此时 MySQL 会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。

?排他锁

排他锁表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。（对于写作来说就是，如果文章正在被修改的时候，其他的读者无法看到这篇文章，其他的编辑也无法修改这篇文章。）

在数据库中使用方法：

SELECT ... FOR UPDATE;

此时 MySQL 会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

有了以上概念的解释，对于锁来说，他们的兼容关系如下：

?

对于以上两个锁来说，我们可以针对粒度对其进行进一步分类，分为表锁和行锁：

• 行锁为给某一行上锁（如果是 X 锁则类似于修改某一篇文章）
• 表锁则为给一个表加上锁（如果是 X 锁则类似于为了更换博客系统而将整个博客下线了），通常用在 DDL 语句中，如 DELETE TABLE,ALTER TABLE 等，由于表锁影响整个表的数据，并发性不如行锁好。

悲观锁小结

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做，一般来说可以使用版本号机制和 CAS 算法实现。

版本号机制

一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数，当数据被修改时，version 值会加一，当读取数据时，将 version 字段的值一同读出，数据每更新一次，对此 version 值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的 version 值进行比对，如果数据库表当前版本号与第一次取出来的 version 值相等，则予以更新，否则认为是过期数据。

对于实现来说，就是：

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

也就是：

CAS 算法

?即 compare and swap（比较与交换），是一种有名的无锁算法。

无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS 算法涉及到三个操作数：

• 需要读写的内存值 V
• 进行比较的值 A
• 拟写入的新值 B

当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试，与 version 事务机制类似，CAS 事务也是一种细粒度的锁。然而，version 为行级锁，粒度过大， 而 CAS 事务为列级锁，粒度更小。根据锁机制的一般原则，粒度越小，并发性能越高。

但是这样也会有一些缺点，例如：

• ABA 问题

比如说一个线程 T1 从内存位置V中取出 A，这时候另一个线程 T2 也从内存中取出 A，并且 T2 进行了一些操作变成了 B，然后 T2 又将 V 位置的数据变成 A，这时候线程 T1 进行 CAS 操作发现内存中仍然是A，然后 T1 操作成功。

• 循环时间长开销大

自旋 CAS（不成功，就一直循环执行，直到成功）如果长时间不成功，会给 CPU 带来非常大的执行开销。

• 只能保证一个共享变量的原子操作

当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性。

乐观锁小结

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

小结

由于数据库中多种多样的锁的存在，帮助我们减少了在对于数据库的并发操作时产生的各种数据不一致的问题，对于这类问题盲目地不使用锁和使用锁都会带来意想不到的灾难，所以我们需要详细了解以应对面试以及实际开发环境中可能遇到的各种坑。

本文作者：Nova Kwok

声明：本文归 “力扣” 版权所有，如需转载请联系。

文中部分图片来源于网络，为非商业用途使用，如有侵权联系删除。