死锁和事务底层原理

一：MySQL中的死锁现象

对于多线程与锁而言，存在一个100%会出现的偶发问题，即死锁问题。

1：何为死锁

1.1：死锁的概念

所谓死锁：就是多个进程之间由于资源的竞争而造成的阻塞现象，如果没有外力作用，这些进程将无法继续推进

和死锁相似的概念是饥饿：等待时间过长以至于给进程推进和响应造成了明显的影响，“饿而不死”

死锁产生的原因：系统的资源竞争、进程推进顺序非法

1.2：死锁产生的四个必要条件：

• 互斥条件：共享资源的排他性访问（互斥是基本前提）
• 不剥夺条件：访问时该共享资源不会被剥夺，而是需要共享资源的进程主动释放（不能蛮横的抢）
• 请求并保持：保持当前的资源而请求另外的资源（不放弃自己的）
• 循环等待条件：存在共享资源的循环等待链（A -> B -> C -> A）

2：MySQL的死锁

2.1：死锁的触发

MySQL与Redis、Nginx这类单线程工作的程序不同，它属于一种内部采用多线程工作的应用，因而不可避免的就会产生死锁问题

举一个简单的转账的例子：

T1等待T2释放锁、T2等待T1释放锁，双方各自等待对方释放锁，一直如此僵持下去，最终就引发了死锁问题

MySQL面对死锁怎么办呢？模拟一下呗：

1：先创建一个表，注意这个表的主键一定要设置成为一会儿update中的where字段

CREATE TABLE `springboot`.`cuihaida_account`  (
`user_name` varchar(255) NOT NULL COMMENT '姓名',
`account` int NOT NULL COMMENT '账户',
PRIMARY KEY (`user_name`) # 因为MySQL记录锁的特性，只有条件命中索引的时候才加的是行锁，否则是表锁
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci;


# 插入两条数据
insert into `cuihaida_account` values ('张三', 100);
insert into `cuihaida_account` values ('李四', 100);

2：开启两个终端，准备进行测试

因此，当死锁问题出现时，MySQL会自动检测并介入，强制回滚结束一个“死锁的参与者（事务）”，从而打破死锁的僵局，让另一个事务能继续执行

2.2：MySQL的死锁如何解决的

对于解决死锁问题可以从多个维度出发，比如预防死锁、避免死锁、解除死锁等，当死锁问题出现后一般只有两种方案：

• 锁超时机制：事务/线程在等待锁时，超出一定时间后自动放弃等待并返回。
• 外力介入打破僵局：第三者介入，将死锁情况中的某个事务/线程强制结束，让其他事务继续执行。

锁超时机制

在InnoDB中其实提供了锁的超时机制，也就是一个事务在长时间内无法获取到锁时，就会主动放弃等待，抛出相关的错误码及信息，然后返回给客户端

时间限制到底是多久呢？可以通过如下命令查询：

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

在50s内未获取到锁的事务，会自动结束并返回。

那也就意味着当死锁情况出现时，这个死锁过程最多持续50s，然后其中就会有一个事务主动退出竞争，释放持有的锁资源

但实际业务中，仅依赖超时机制去解除死锁是不够的，毕竟高并发情况下，50s时间太长了，会导致越来越多的事务阻塞。

这个参数调小会好吗？

参数调小之后确实能确保死锁发生后，在很短的时间内可以自动解除

但改掉了这个参数之后，也会影响正常事务等待锁的时间，也就是大部分未发生死锁，但需要等待锁资源的事务，在等待短时间之后，就会立马报错并返回

这显然并不合理，毕竟容易误伤“友军”。

死锁检测算法(wait-for graph)

这种算法是专门用于检测死锁问题的，在该算法中会对于目前库中所有活跃的事务生成等待图，例如：【可以类比os死锁中的死锁定理中的资源分配图】

当MySQL发现了这种等待闭环时，就会强制介入，回滚结束其中一个事务，强制打破该闭环，从而解除死锁问题。

wait-for graph是怎么工作的？[了解下即可]

wait-for graph算法被启用后，会要求MySQL收集两个信息：

• 锁的信息链表：目前持有每个锁的事务是谁。
• 事务等待链表：阻塞的事务要等待的锁是谁。

每当一个事务需要阻塞等待某个锁时，就会触发一次wait-for graph算法

该算法会以当前事务作为起点，然后从「锁的信息链表」中找到对应中锁信息。再去根据锁的持有者（事务），在「事务等待链表」中进行查找，看看持有锁的事务是否在等待获取其他锁，如果是，则再去看看另一个持有锁的事务，是否在等待其他锁…，经过一系列的判断后，再看看是否会出现闭环，出现的话则介入破坏。就形成了类似于下面的这张图：

此时当T3事务需要阻塞等待获取X1锁时，就会触发一次wait-for graph算法，流程如下：

1. 先根据T3要获取的X1锁，在「锁的信息链表」中找到X1锁的持有者T1。
2. 再在「事务等待链表」中查找，看看T1是否在等待获取其他锁，此时会得知T1等待X2。
3. 再去「锁的信息链表」中找到X2锁的持有者T2，再看看T2是否在阻塞等待获取其他锁。
4. 再在「事务等待链表」中查找T2，发现T2正在等待获取X3锁，再找X3锁的持有者。

经过上述一系列算法过程后，最终会发现X3锁的持有者为T3，而本次算法又正是T3事务触发的，此时又回到了T3事务，也就代表着产生了“闭环”，因此也可以证明这里出现了死锁现象，所以MySQL会强制回滚其中的一个事务，来抵达解除死锁的目的。

出现死锁问题时，MySQL会选择哪个事务回滚呢？

当一个事务在执行SQL更改数据时，都会记录在Undo-log日志中

Undo量越小的事务，代表它对数据的更改越少，同时回滚的代价最低，因此会选择Undo量最小的事务回滚

如若两个事务的Undo量相同，会选择回滚触发死锁的事务

🎉 可以通过innodb_deadlock_detect=on|off这个参数，来控制是否开启死锁检测机制。

⚠️死锁检测机制在MySQL后续的高版本中是默认开启的，但实际上死锁检测的开销不小，当阻塞的并发事务越来越多时，检测的效率也会呈线性增长

如何避免死锁产生

因为死锁的检测过程较为耗时，所以尽量不要等死锁出现后再去解除，而是尽量调整业务避免死锁的产生，一般来说可以从如下方面考虑：

• 合理的设计索引结构，使业务SQL在执行时能通过索引定位到具体的几行数据，减小锁的粒度。
• 业务允许的情况下，也可以将隔离级别调低，因为级别越低，锁的限制会越小。
• 调整业务SQL的逻辑顺序，较大、耗时较长的事务尽量放在特定时间去执行（如凌晨对账…）。
• 尽可能的拆分业务的粒度，一个业务组成的大事务，尽量拆成多个小事务，缩短一个事务持有锁的时间。
• 如果没有强制性要求，就尽量不要手动在事务中获取排他锁，否则会造成一些不必要的锁出现，增大产生死锁的几率。
• …

🎉 简单来说，在业务允许的情况下，尽量缩短一个事务持有锁的时间、减小锁的粒度以及锁的数量。

⚠️ 当MySQL运行过程中产生了死锁问题，那这个死锁问题以后绝对会再次出现，当死锁被MySQL自己解除后，一定要记住去排除业务SQL的执行逻辑，找到产生死锁的业务，然后调整业务SQL的执行顺序，这样才能从根源上避免死锁产生

二：锁机制的底层实现原理

1：锁的内存结构

在Java中，Synchronized锁是基于Monitor实现的，而ReetrantLock又是基于AQS实现的，那MySQL的锁是基于啥实现的呢？

锁的事务信息

其中记录着当前的锁结构是由哪个事务生成的，记录的是指针，指向一个具体的事务。

索引信息

这个是行锁的特有信息，对于行锁来说，需要记录一下加锁的行数据属于哪个索引、哪个节点，记录的也是指针

锁粒度信息

对于不同粒度的锁，其中存储的信息也并不同：

• 如果是表锁，其中就记录了一下是对哪张表加的锁，以及表的一些其他信息。

• 如果锁粒度是行锁，其中记录的信息更多，有三个较为重要的：

  • Space ID：加锁的行数据，所在的表空间ID。

  • Page Number：加锁的行数据，所在的页号。

  • n_bits：使用的比特位，对于一页数据中，加了多少个锁（后续结合讲）。

锁类型信息

对于锁结构的类型，在内部实现了复用，采用一个32bit的type_mode来表示

这个32bit的值可以拆为lock_mode、lock_type、rec_lock_type三部分

lock_mode：表示锁的模式，使用低四位。

• 0000/0：表示当前锁结构是共享意向锁，即IS锁。
• 0001/1：表示当前锁结构是排他意向锁，即IX锁。
• 0010/2：表示当前锁结构是共享锁，即S锁。
• 0011/3：表示当前锁结构是排他锁，即X锁。
• 0100/4：表示当前锁结构是自增锁，即AUTO-INC锁。

lock_type：表示锁的类型，使用低位中的5~8位。

• LOCK_TABLE：当第5个比特位是1时，表示目前是表级锁。
• LOCK_REC：当第6个比特位是1时，表示目前是行级锁。

rec_lock_type：表示行锁的具体类型，使用其余位。

• LOCK_ORDINARY：当高23位全零时，表示目前是临键锁。
• LOCK_GAP：当第10位是1时，表示目前是间隙锁。
• LOCK_REC_NOT_GAP：当第11位是1时，表示目前是记录锁。
• LOCK_INSERT_INTENTION：当第12位是1时，表示目前是插入意向锁。
• .....：内部还有一些其他的锁类型，会使用其他位。

is_waiting：表示目前锁处于等待状态还是持有状态，使用低位中的第9位。

• 0：表示is_waiting=false，即当前锁无需阻塞等待，是持有状态。
• 1：表示is_waiting=true，即当前锁需要阻塞，是等待状态。

例如上面这个图，表示一个阻塞等待的行级排他临键锁结构。

其他信息

这个所谓的其他信息，也就是指一些用于辅助锁机制的信息，例如wait-for graph中的两个辅助链表

锁的比特位

与其说是锁的比特位，不如说是数据的比特位，好比举个例子：

student_id	name	sex	height
1	xx	男	111
2	xxx	女	111
3	xxxx	女	112
4	xxxxx	男	112
5	xxxxxx	男	122
6	xxxxxxx	女	112
7	xxxxxxxx	男	122

学生表中有七条数据，此时就会形成一个比特数组：000000000

明明只有七条数据，为啥会有9个比特位呢？

因为行锁中，间隙锁可以锁定无穷小、无穷大这两个间隙，因此这组比特中，首位和末位即表示无穷小、无穷大两个间隙。

好比此时T1事务，对ID=2、3、6这三条数据加锁了，此时这个比特数组就会变为001100100，表示T1事务同时锁定了三条数据。

而之前聊到的n_bits，它就会记录一下在这组比特中，多少条记录被上锁了。

2：InnoDB的锁优化实现

如果一个事务同时需要对表中的1000条数据加锁，会生成1000个锁结构吗？

MySQL是基于事务实现的锁，当下面述四点条件被满足时，符合条件的行记录会被放入到同一个锁结构中

• 目前对表中不同行记录加锁的事务是同一个。（同事务）
• 需要加锁的记录在同一个页面中。（同页）
• 目前事务加锁的类型都是相同的。（同类型）
• 锁的等待状态也是相同的。（同等待状态）

假设加锁的1000条数据分布在3个页面中，同时表中没有其他事务在操作，加的都是同一类型的锁。

此时依据上述的前提条件，那在内存中仅会生成三个锁结构，能够很大程度上减少锁结构的数量

3：MySQL获取锁的过程

当一个事务需要获取某个行锁时，首先会看一下内存中是否存在这条数据的锁结构

如果存在则生成一个锁结构，将其is_waiting对应的比特位改为1，表示目前事务在阻塞等待获取该锁

当其他事务释放锁后，会唤醒当前阻塞的事务，然后会将其is_waiting改为0，接着执行SQL。

事务获取锁时，是如何在内存中，判断是否已经存在相同记录的锁结构呢？

还记得锁结构中会记录的一个信息嘛？也就是「锁粒度信息」，如果是表锁，会记录表信息，如果是行锁，会记录表空间、页号等信息。在事务获取锁时，就是去看内存中，已存在的锁结构的这个信息，来判断是否存在其他事务获取了锁。

释放锁的过程也比较简单，这个工作一般是由MySQL自己完成的，当事务结束后会自动释放，释放的时候会去看一下，内存中是否有锁结构，正在等待获取目前释放的锁，如果有则唤醒对应的线程/事务。

三：事务隔离机制的底层实现

• RU/读未提交级别：要求该隔离级别下解决脏写问题。
• RC/读已提交级别：要求该隔离级别下解决脏读问题。
• RR/可重复读级别：要求该隔离级别下解决不可重复读问题。【其实这里已经解决了幻读问题，就是临键锁 + MVCC】
• Serializable/序列化级别：要求在该隔离级别下解决幻读问题。

1：读未提交RU的底层实现

RU级别要求一个事务可以读到其他事务未提交的数据，但同时要求解决脏写（更新覆盖）问题

假设没有加锁

因此，对于解决脏写问题，RU采取的是读取的时候不加锁，写入的时候加入排他锁，防止其他事务的写覆盖掉自己的写

2：读已提交RC的底层实现

RC级别要求解决脏读问题，也就是一个事务中，不允许读另一个事务还未提交的数据

RC级别的底层实现，对于写操作会加排他锁，而读操作会使用MVCC机制。

但由于每次select时都会生成ReadView快照，此时就会出现下述问题：

此时观察这个案例，明明是在一个事务中查询同一条数据，结果两次查询的结果并不一致，这也是所谓的不可重复读的问题。

3：可重复读RR的底层实现

在RC级别中，虽然解决了脏读问题，但依旧存在不可重复读问题，而RR级别中，就是要确保一个事务中的多次读取结果一致，即解决不可重复读问题

两种方案：

• 查询时，对目标数据加上临键锁，即读操作执行时，不允许其他事务改动数据
• MVCC机制的优化版：一个事务中只生成一次ReadView快照

4：序列化的底层实现

在这个级别中，要求解决所有可能会因并发事务引发的问题

序列化就是所有写操作加临键锁（具备互斥特性），所有读操作加共享锁。

由于所有写操作在执行时，都会获取临键锁，所以写-写、读-写、写-读这类并发场景都会互斥

由于读操作加的是共享锁，因此在Serializable级别中，只有读-读场景可以并发执行。

5：总结

• U级别：读操作不加锁，写操作加排他锁。
• RC级别：读操作使用MVCC机制，每次SELECT生成快照，写操作加排他锁。
• RR级别：读操作使用MVCC机制，首次SELECT生成快照，写操作加临键锁。
• 序列化级别：读操作加共享锁，写操作加临键锁。

级别/场景	读-读	读-写/写-读	写-写
RU级别	并行执行	并行执行	串行执行
RC级别	并行执行	并行执行	串行执行
RR级别	并行执行	并行执行	串行执行
序列化级别	并行执行	串行执行	串行执行