MySQL 中的锁(三)

8.7. 死锁和空间锁

一般来说,只要有并发和加锁这两种情况的共同加持下,都会有死锁的身影。
死锁的具体成因,借用我们在并发编程中的内容:

8.7.1. 死锁

8.7.1.1. 概念

是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信
而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统
处于死锁状态或系统产生了死锁。
举个例子:A 和 B 去按摩洗脚,都想在洗脚的时候,同时顺便做个头部按摩,13 技师擅长足底按摩,14 擅长头部按摩。

这个时候 A 先抢到 14,B 先抢到 13,两个人都想同时洗脚和头部按摩,于是就互不相让,扬言我死也不让你,这样的话,A 抢到 14,想要 13,B 抢到 13,想要 14,在这个想同时洗脚和头部按摩的事情上 A 和 B 就产生了死锁。怎么解决这个问题呢?
第一种,假如这个时候,来了个 15,刚好也是擅长头部按摩的,A 又没有两个脑袋,自然就归了 B,于是 B 就美滋滋的洗脚和做头部按摩,剩下 A 在旁边气鼓鼓的,这个时候死锁这种情况就被打破了,不存在了。
第二种,C 出场了,用武力强迫 A 和 B,必须先做洗脚,再头部按摩,这种情况下,A 和 B 谁先抢到 13,谁就可以进行下去,另外一个没抢到的,就等着,这种情况下,也不会产生死锁。

所以总结一下:
死锁是必然发生在多操作者(M>=2 个)情况下,争夺多个资源(N>=2 个,且 N<=M)才会发生这种情况。很明显,单线程自然不会有死锁,只有 B 一个去,不要 2 个,打十个都没问题;单资源呢?只有 13,A 和 B 也只会产生激烈竞争,打得不可开交,谁抢到就是谁的,但不会产生死锁。同时,死锁还有几个要求,
1、争夺资源的顺序不对,如果争夺资源的顺序是一样的,也不会产生死锁;
2、争夺者拿到资源不放手。

8.7.1.2. 学术化的定义

死锁的发生必须具备以下四个必要条件。
1)互斥条件:指进程对所分配到的资源进行排它性使用,即在一段时间内
某资源只由一个进程占用。如果此时还有其它进程请求资源,则请求者只能等待,
直至占有资源的进程用毕释放。
2)请求和保持条件:指进程已经保持至少一个资源,但又提出了新的资源
请求,而该资源已被其它进程占有,此时请求进程阻塞,但又对自己已获得的其
它资源保持不放。
3)不剥夺条件:指进程已获得的资源,在未使用完之前,不能被剥夺,只
能在使用完时由自己释放。
4)环路等待条件:指在发生死锁时,必然存在一个进程——资源的环形链,
即进程集合{P0,P1,P2,···,Pn}中的 P0 正在等待一个 P1 占用的资源;P1
正在等待 P2 占用的资源,……,Pn 正在等待已被 P0 占用的资源。

理解了死锁的原因,尤其是产生死锁的四个必要条件,就可以最大可能地避免、预防和解除死锁。
只要打破四个必要条件之一就能有效预防死锁的发生。
打破互斥条件:改造独占性资源为虚拟资源,大部分资源已无法改造。
打破不可抢占条件:当一进程占有一独占性资源后又申请一独占性资源而无法满足,则退出原占有的资源。
打破占有且申请条件:采用资源预先分配策略,即进程运行前申请全部资源,满足则运行,不然就等待,这样就不会占有且申请。
打破循环等待条件:实现资源有序分配策略,对所有设备实现分类编号,所有进程只能采用按序号递增的形式申请资源。
避免死锁常见的算法有有序资源分配法、银行家算法。

8.7.1.3. MySQL 中的死锁

所以 MySQL 中的死锁的成因是一样的。
会话 1:

begin;
select * from teacher where number = 1 for update;

MySQL 中的锁(三)_第1张图片
会话 2:

begin;
select * from teacher where number = 3 for update;

MySQL 中的锁(三)_第2张图片
会话 1:

select * from teacher where number = 3 for update;

可以看到这个语句的执行将会被阻塞
会话 2:

select * from teacher where number = 1 for update;

在这里插入图片描述
MySQL 检测到了死锁,并结束了会话 2 中事务的执行,此时,切回会话 1,发现原本阻塞的 SQL 语句执行完成了。
MySQL 中的锁(三)_第3张图片
同时通过

show engine innodb status\G

可以看见死锁的详细情况:

8.7.2. Predicate Locks for Spatial Indexes

从 MySQL5.7 开始 MySQL 整合了 boost.geometry 库以更好的支持空间数据类型,并支持在在 Spatial 数据类型的列上构建索引,在 InnoDB 内,这个索引和普通的索引有所不同,基于 R-TREE 的结构,目前支持对 2D 数据的描述,暂不支持 3D.
R-TREE 和 BTREE 不同,它能够描述多维空间,而多维数据并没有明确的数据顺序,因此无法在 RR 隔离级别下构建 NEXT-KEY 锁以避免幻读,因此 InnoDB使用称为 Predicate Lock 的锁模式来加锁,会锁住一块查询用到的被称为MBR(minimum boundingrectangle/box)的数据区域。 因此这个锁不是锁到某个具
体的记录之上的,可以理解为一种 Page 级别的锁。
Predicate Lock 和普通的记录锁或者表锁(如上所述)存储在不同的 lock hash中,其相互之间不会产生冲突。

你可能感兴趣的:(mysql,数据库)