死锁

死锁

当两个以上的运算单元，双方都在等待对方停止运行，以获取系统资源，但是没有一方提前退出时，就称之为死锁。

死锁问题是计算机系统中常见的问题，在Innodb中同样存在。

死锁的产生条件

死锁产生必须要满足以下四个条件：

互斥条件: 即为某个资源在同一时间只允许被一个单元占有。
不可抢占条件:被单元占有的资源不可被其它单元抢占。
占有且申请条件:单元当前至少占有一个资源，且该单元同时向系统申请其它的资源。
循环等待条件:单元之前存在一个资源的循环等待序列。

死锁范例

在百度上盗了一张图，如图所示，单元T1和T2各自占有了一个资源，又同时想要占据别人的资源，这样僵持不下，也就产生了死锁。对于计算机系统而言，死锁会导致系统停滞，对于Innodb而言，死锁会给数据的读写产生阻碍。

Innodb中的死锁

引言

在介绍之前，先讲一个我们工作中踩到的一个坑。

背景描述

我们的订单表中存在一个Unique Key，假设该Unique Key的名字为U_KEY，它是由一个ID和时间戳构成的。在实际运行中，存在用同一个Unique Key反复创建订单的行为，这种情况的发生有可能是因为恶意刷单或者是偶然的请求重发。对于这种情况，先到达的插入请求会成功，之后的请求会产生Unique Key冲突而失败，但这个过程中会时不时的出现Dead Lock Detected的情况(数据库会自动Kill死锁)，这里我们采用的是insert ignore。

问题原因

在插入时，MySQL会给行记录加上排他锁(Index-record lock)，假如此时有三个同样的插入请求，都开启了事务，其中一个先拿到了排他锁开始插入，之后的事务会出现Duplicate Key错误，而此时它们会申请该行的共享锁，如果这个时候拿到排他锁的事务回滚，那么另外两个事务会同时申请该行的排他锁（过程参考MySQL锁机制。由于排他锁和共享锁是互斥的，此时就产生了死锁的情况。

这里可能会有人有疑问，为什么出现Duplicate Key错误的时候会加共享锁了，我的理解是冲突检测本身是一种读操作，所以冲突之后的轮询需要加共享锁。据这个例子的主要目的是告诉大家死锁问题是我们工作中会遇到的，需要重视。