5-4. 死锁的处理在线视频

下面我们来介绍一下死锁的处理

我们前面讲了，虽然我们使用了严格的两阶段锁协议或者是强两阶段锁协议

它们只能解决不正确的加锁问题以及级联回滚

但是对于死锁的问题还没有完全的解决，下面我们就来看一下

关于死锁我们数据库管理系统是如何处理的

我们前面已经知道了死锁就是事务处于相互等待的状态

他们都相互等待对方释放资源

处理死锁的方法有两种

一种是采用预防的方式，我们叫死锁预防协议

预防的目的就是说我从一开始就让系统不进入死锁状态

那么怎么去做呢

一般的来说是对加锁请求进行排序

我在事务执行之前就先排好了序

后面我们来说一下，再有一种就是我允许系统进入死锁状态

但是我们需要引入一种检测机制

也就是说，我时不时的就在系统之中检测一下或看看目前有没有死锁

如果有死锁的话，我就采用一种恢复机制来进行恢复

下面我们先看一下死锁的预防

那我们说，死锁的预防它实际上是对事务执行的一个排序

排序基本上是采用两种机制

一种是采用抢占与事务回滚机制

这个抢占与事务回滚机制它的基本措施是这样的

我给每一个事务都赋一个时间戳

如果一个事务回滚的话，我必须要重新启动它

那么我启动的时候，它必须要保持事务原来赋给它的时间戳

然后有了这个时间戳之后，我们就采用以下的机制

一种机制就是wait-die，我们翻译成中文就是等待死亡

假如说一个事务T1申请的数据正在被T2持有

那么什么时候T1等待呢？

只有T1比T2年轻，也就是说T1比T2后启动

也就是T1的时间戳大于T2的时间戳，意思就是T2比T1先启动

只有这个时候T1采取等待，否则T1就回滚

采用这样一种方式我们可以对事务进行一个排序

第二种方式就是wound-wait，受伤的等待

它们条件也与前面相同，比如说T1申请的数据被T2持有

那么这个时候什么时候T1等待呢？

正好相反，也就是说T1如果启动的比T2早，那T1就等待

也就是说更年老的事务去等待，年轻的事务去回滚

采用这样一种机制对整个事务进行一种排序，使得他们能避免进入一种死锁状态

这就是抢占与事务回滚技术

那么第二种机制是采用的是基于超时的机制

这种机制是事先给出事务的等待时间，每一个事务给一个等待时间

比如说给它一百微秒，或者是给它多少毫秒

如果这个等待时间超时的话，还没有获得数据上的锁，那它就回滚

接下来再重新给它赋予一个等待时间，按照这样一种方式

死锁的预防，虽然说提出了这样一些技术

但是实际上在真正实现的时候并不多，因为也非常的复杂

那么一般的数据库管理系统采用的是死锁检验技术，而不是预防

也就是说它允许你事务先去执行，允许你事务在执行过程中出现死锁

但是系统可以周期性的对这个死锁进行检测

它怎么去检测呢？它是通过一个等待处理

这个等待图特别类似于前面讲的冲突可串行化的图一样

它也是由节点和有向弧所表示

节点表示事务，有向弧指向例如T1指向T3

指的是T1持有等待T3释放数据项的锁，是这样的一种含义

那么我们根据事务这样一种等待关系，就画出了一个等待图

如果这张图里面没有环，就说明没有进入死锁状态

如果这张图里面有环，比如说这个ppt里面的第二个

右面这张图T1等待T3释放锁，T3等待T4释放锁，T4又等待T1释放锁

显然它就进入了一个循环状态，它就进入了一个死锁状态

如果它进入死锁状态，我们必须要把这种死锁状态解开

怎么去解开呢？就是说我们把这个环要打破

必须把这个环去打破，这个环去打破的话

就希望在这个环上对某一些事务进行回滚

哪些事务进行回滚呢？

当然我们要选择一些回滚代价最小的，比如说它现在执行的时间短

或者说把它回滚之后，我们对数据库的修复，修复的代价小等等

我们要采用这样一种方式来选择回滚的事务

当然如果这样去选择事务回滚，也会遇到这样的问题

每次回滚都选择这个事务，这个事务最后就会被饿死，产生饿死现象

在这种情况下，我们就要加入一些其他的

比如说，我们可以把回滚次数考虑在代价里面，给它赋予一个优先权

防止某些事务老是被回滚，它不被执行

一般现在的数据库管理系统，比如像SQL Server

实际上它们使用的都是死锁检验，它会周期性的

也就是说运行当中它周期性的检测是否有死锁发生

这个周期的长短它是受死锁发生的频率以及受影响事务的数量这两个因素有关

到此为止，我们就把基于锁的协议给大家介绍到这里

那么我们通过上面的一些介绍，对锁协议的基本原理有了一个基本的认识

我们知道锁协议实际上还是一个比较复杂的

应该说开销也比较大，但是实际上并发的效率还不是特别高

但是它比较简单，这章大家需要重点的了解

锁的基本概念、锁的模式以及锁的调度策略和两阶段锁协议

以及两阶段锁协议基础之上，我们对于死锁的处理

这个是需要大家理解并且掌握的内容