死锁

快来打我* 2021-12-09 01:04 448阅读 0赞

## 一、死锁的概念 ##

**死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象。**若无外力作用，事务都将无法推进下去。

解决死锁问题最简单的方式是不要等待，将任何的等待都转化为回滚，并且事务重新开始。然而在线上环境中，这可能导致并发性能的下降，甚至任何一个事务都不能进行。而这锁带来的问题远比死锁问题更严重，因为这很难被发现并且浪费资源。

**　解决死锁问题**最简单的**一种方**式是超时，即当两个事务互相等待时，当一个等待时间超过设置的某一阈值时，其中一个事务进行回滚，另一个等待的事务就能继续进行。**在InnoDB存储引擎中，参数innodb\_lock\_wait\_timeout用来设置超时的时间。**

**　　**超时机制虽然简单，但是其仅通过超时后对事务进行回滚的方式来处理，或者说其根据FIFO的顺序选择回滚对象。但若超时的事务所占权重比较大，如事务操作更新了很多行，占用了较多的undo log，这时采用FIFO的方式，就显得不合适了，因为回滚这个事务的时间想对另一个事务所占时间可能会很多。

因此，除了超时机制，当前数据库还普遍采用wait-for graph（等待图）的方式来进行死锁检测。这是一种更为主动的死锁检测方式。InnoDB存储引擎也采用的这种方式。

**wait-for graph要求数据库保存以下两种信息**：

1、锁的信息链表

2、事务等待链表

通过以上链表可以构造处一张图，而这个图中若存在回路，就代表存在死锁，因此资源间相互发生等待。**wait-for graph**中，事务为图中的节点。在图中，事务T1指向T2边的定义：

事务T1等待事务T2所占用的资源

事务T1最终等待T2所占用的资源，也就是事务之间在等待相同的资源，而事务T1发生在事务T2的后面

![1007094-20190707101817516-994528658.png][]

在Transaction wait Lists中可看到共有4个事务t1，t2，t3，t4，故在wait-for graph中应有4个节点。而事务t2对row1占用x锁，事务t1对row2占用s锁。事务t1需要等待事务t2中row1的资源，因此wait-for graph中有条边从节点t1指向节点t2。事务t2需要等待事务t1，t4所占用的row2对象，故而存在节点t2到节点t1，t4的边。同样，存在t3到节点t1，t2，t4的边，因此最终的wait-for graph如图

![1007094-20190707102531530-1576231482.png][]

## **二、死锁示例** ##

**　　1、示例1**

**　**　A等待B，B等待A，这种死锁问题被称为AB-BA死锁。

**![1007094-20190714180130699-996386181.png][]**

以上操作中，B的事务抛出了1213错误，即表示事务发生了死锁。

死锁的原因是会话A和B的资源在相互等待。

大多数的死锁InnoDB存储引擎本身可以侦测到，不需要人为进行干预。

在会话B中的事务抛出死锁异常后，会话A中马上得到了记录为2的这个资源，这其实是因为会话B中的事务发生了回滚，否则会话A中的事务不可能得到资源。

InnoDB存储引擎不会回滚大部分的错误异常，但是死锁除外。发现死锁后，InnoDB存储引擎会马上回滚一个事务。

Oracle产生死锁的常见原因是没有对外键添加索引，而InnoDB存储引擎会自动对其添加，因而能很好的避免这种情况。

[1007094-20190707101817516-994528658.png]: /images/20211209/bf771991b9094cfdbef153a2d2acf3e4.png
[1007094-20190707102531530-1576231482.png]: /images/20211209/5a6c858f3fa1497aa8dbd389cab3c541.png
[1007094-20190714180130699-996386181.png]: /images/20211209/467ac8849a4243cfa5f74a2b4ee4b1e2.png

死锁

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁

相关死锁