1、死锁的概念
死锁是指两个或两个以上的事务在执行过程中,因争夺锁资源而造成的一种互相等待的现象。若无外力作用,事务都将无法推进下去。解决死锁问题最简单的方式是不要有等待,将任何的等待都转化为回滚,并且事务重新开始。毫无疑问,这的确可以避免死锁问题的产生。然而在线上环境中,这可能导致并发性能的下降,甚至任何一个事务都不能进行。而这所带来的问题远比死锁问题更为严重,因为这很难被发现并且浪费资源。
解决死锁问题最简单的一种方法是超时,即当两个事务互相等待时,当一个等待时间超过设置的某一阈值时,其中一个事务进行回滚,另一个等待的事务就能继续进行。
在 InnoDB存储引擎中,参数 innodb_lock_wait_timeout用来设置超时的时间超时机制虽然简单,但是其仅通过超时后对事务进行回滚的方式来处理,或者说其是根据FIFO的顺序选择回滚对象。但若超时的事务所占权重比较大,如事务操作更新了很多行,占用了较多的 undo log,这时采用FIFO的方式,就显得不合适了,因为回滚这个事务的时间相对另一个事务所占用的时间可能会很多。
因此,除了超时机制,当前数据库还都普遍采用wait-for graph(等待图)的方式来进行死锁检测。较之超时的解决方案,这是一种更为主动的死锁检测方式。 InnoDB存储引擎也采用的这种方式。wait-for graph要求数据库保存以下两种信息:
- 锁的信息链表
- 事务等待链表
通过上述链表可以构造出一张图,而在这个图中若存在回路,就代表存在死锁,因此资源间相互发生等待。在 wait-for graph中,事务为图中的节点。而在图中,事务T1指向T2边的定义为:
- 事务T1等待事务T2所占用的资源
- 事务T1最终等待T2所占用的资源,也就是事务之间在等待相同的资源,而事务T1发生在事务T2的后面
下面来看一个例子,当前事务和锁的状态如图所示。
在 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如图所示。
通过图6-6可以发现存在回路(t1,t2),因此存在死锁。通过上述的介绍,可以发现wait-for graph是一种较为主动的死锁检测机制,在每个事务请求锁并发生等待时都会判断是否存在回路,若存在则有死锁,通常来说InnoDB存储引擎选择回滚undo量最小的事务。
wait-for graph的死锁检测通常采用深度优先的算法实现,在 InnoDB1.2版本之前,都是采用递归方式实现。而从1,2版本开始,对 wait-for graph的死锁检测进行了优化,将递归用非递归的方式实现,从而进一步提高了 InnoDB存储引擎的性能。
2、死锁概率
死锁应该非常少发生,若经常发生,则系统是不可用的。此外,死锁的次数应该还要少于等待,因为至少需要2次等待才会产生一次死锁。本节将从纯数学的概率角度来分析,死锁发生的概率是非常小的。
假设当前数据库中共有n+1个线程执行,即当前总共有n+1个事务。并假设每个事务所做的操作相同。若每个事务由r+1个操作组成,每个操作为从R行数据中随机地操作一行数据,并占用对象的锁。每个事务在执行完最后一个步骤释放所占用的所有锁资源。最后,假设nr<<R,即线程操作的数据只占所有数据的一小部分在上述的模型下,事务获得一个锁需要等待的概率是多少呢?当事务获得一个锁,其他任何一个事务获得锁的情况为
(1+2+3+…+r)/(r+1)≈r/2由于每个操作为从R行数据中取一条数据,每行数据被取到的概率为1/R,因此,事务中每个操作需要等待的概率PW为:
PW=nr/2R事务是由r个操作所组成,因此事务发生等待的概率PW(T)为:
死锁是由于产生回路,也就是事务互相等待而发生的,若死锁的长度为2,即两个等待节点间发生死锁,那么其概率为:
由于大部分死锁发生的长度为2,因此上述公式基本代表了一个事务发生死锁的概率。从整个系统来看,任何一个事务发生死锁的概率为:
从上述的公式中可以发现,由于m<R,因此事务发生死锁的概率是非常低的。同时,事务发生死锁的概率与以下几点因素有关:
- 系统中事务的数量(n),数量越多发生死锁的概率越大。
- 每个事务操作的数量(),每个事务操作的数量越多,发生死锁的概率越大,
- 操作数据的集合(R),越小则发生死锁的概率越大。
3、死锁的示例
如果程序是串行的,那么不可能发生死锁。死锁只存在于并发的情况,而数据库本身就是一个并发运行的程序,因此可能会发生死锁。下表的操作演示了死锁的一种经典的情况,即A等待B,B在等待A,这种死锁问题被称为AB-BA死锁。
死锁用例1
时间 | 会话A | 会话B |
1 | BEGIN | |
2 | SELECT * FROM t WHERE a=1 FOR UPDATE a:1 | BEGIN |
3 | | SELECT * FROM t WHERE a=2 FOR UPDATE a:2 |
4 | SELECT * FROM t WHERE a=2 FOR UPDATE #等待 | |
5 | | SELECT * FROM t WHERE a=1 FOR UPDATE ERROR 1213(40001): Deadlock found when trying to get lock; try restarting transaction |
在上述操作中,会话B中的事务抛出了1213这个错误提示,即表示事务发生了死锁。死锁的原因是会话A和B的资源在互相等待。大多数的死锁 InnoDB存储引擎本身可以侦测到,不需要人为进行干预。但是在上面的例子中,在会话B中的事务抛出死锁异常后,会话A中马上得到了记录为2的这个资源,这其实是因为会话B中的事务发生了回滚,否则会话A中的事务是不可能得到该资源的。
InnoDB存储引擎并不会回滚大部分的错误异常,但是死锁除外。发现死锁后, InnoDB存储引擎会马上回滚一个事务,这点是需要注意的。因此如果在应用程序中捕获了1213这个错误,其实并不需要对其进行回滚。
此外还存在另一种死锁,即当前事务持有了待插入记录的下一个记录的ⅹ锁,但是在等待队列中存在一个S锁的请求,则可能会发生死锁。来看一个例子,首先根据如下代码创建测试表t,并导入一些数据:
CREATE TABLE t(
a INT PRIMARY Key
)ENGINE=InnoDB;
INSERT INTO t VALUES(1),(2),(4),(5);表t仅有一个列a,并插入4条记录。接着运行下表所示的查询。
死锁用例2
时间 | 会话A | 会话B |
1 | BEGIN | |
2 | | BEGIN |
3 | SELECT * FROM t WHERE a=4 FOR UPDATE | |
4 | | SELECT * FROM t WHERE a < 4 LOCK IN SHARE MODE #等待 |
5 | INSERT INTO t VALUES(3); ERROR 1213(40001): Deadlock found when trying to get lock; try restarting transaction | |
6 | | #事务获得锁,正常运行 |
可以看到,会话A中已经对记录4持有了X锁,但是会话A中插入记录3时会导致死锁发生。这个问题的产生是由于会话B中请求记录4的S锁而发生等待,但之前请求的锁对于主键值记录1、2都已经成功,若在事件点5能插入记录,那么会话B在获得记录4持有的S锁后,还需要向后获得记录3的记录,这样就显得有点不合理。因此 InnoDB存储引擎在这里主动选择了死锁,而回滚的是 undo log记录大的事务,这与AB-BA死锁的处理方式又有所不同。
