2PL——2阶段锁存在的问题

在这里插入图片描述
两阶段锁协议通常包括扩张和收缩两个阶段。在扩张阶段，事务将获取锁，但不能释放任何锁。在收缩阶段，可以释放现有的锁，但不能获取新的锁。上图是一个典型的遵循2PL协议的序列表。看似严格保证了序列化，但实际存在着死锁的风险。
例如：当T1’在扩张阶段，获取了Y的读锁，并读取了Y，此时想要去获取X的写锁，却发现T2’的读锁锁定了X，而T2’也想要获取Y的写锁。简而言之，T1’不得到X是不会释放Y的，T2’不得到Y也是不会释放X的，这便陷入了循环，便形成了死锁。
本文就这一问题展开对死锁的两种处理方法的介绍，希望能用更通俗的语言让大家理解

一、死锁与等待图

1. 死锁（Deadlock）

死锁是指集合中的每个事务都在等待队列中，等待其他事务释放某个项上的锁。但是因为另一个事务也在等待，所以它永远不会释放锁。简而言之就是，我在等你主动，你也在等我主动，最后的结果是我俩都陷入僵局，什么都做不了。

通常检验一个事务执行序列是否发生死锁，可以用等待图（wait-for graph）来形象地描述。还是拿上面的例子来说。

图(a)就是我在上文中描述死锁的产生过程。图(b)就是等待图，从图中我们可以形象地看到，T1’在向T2’索取X，T2’在向T1索取Y，这便在图中形成了环，便发生了死锁。
死锁一旦发生，进程或事务将面临饥饿(Starvation)，甚至最终饿死。

2. 等待图（Wait-for graph）

等待图是一种分析死锁的有效工具。它是有向图，其中节点表示事务，带有箭头的有向边表示“等待”关系，箭头的方向就是等待的方向。例如，上图(b)中，T1’在等待T2’的X，T2’在等待T1’的Y。
定理：当且仅当等待图中至少存在一个环，则存在一个死锁。

示例：针对下图给出的序列，若用r表示读，w表示写，S表示读锁，X表示写锁，US表示释放读锁，UX表示释放写锁。
S1(X) r1(X); S2(Z) r2(Z); S3(X) r3(X); S1(Z) US1(X) r1(Z); S2(Y) US2(Z) r2(Y); X2(Z) US2(Y) w2(Z); X1(X) US1(Z) w1(X); X3(Y) US3(X) w3(Y); X2(Y) UX2(Z) w2(Y); UX2(Y)
在这里插入图片描述

转化为等待图为：
在这里插入图片描述
这样便形成了一个闭环，故发生了死锁。

二、死锁的处理手段

1. 死锁预防

如何来预防死锁的发生？
有人说：那我可以保守一点，直接让每个事务在执行前直接先把需要读写的项目，全部锁定。如果无法全部锁定，那我就一直等待，直到可以全部锁定我才开始这项事务。
显然，这个方案严重降低了并发性，并不是一个优秀的方案。
又有人说：那我可以对这些待读写的项目提前排个序啊，确保事务在执行过程中可以顺利锁定它们不就好了。这显然是不切实际的，这要求系统或程序提前知道待读写的项目的操作顺序。同样的这也大幅降低了并发性。

为了保证并发性，我们考虑在发现即将有死锁的苗头时，主动让事务中止回滚或阻塞等待。下面介绍一种基于时间戳的死锁预防协议。它分为剥夺式和非剥夺式的。
首先引入事务时间戳这一概念，用TS(Ti)表示，数值越小代表开始越早，也表示该事务越“老”。例如上面的例子中，最早开始的事务是T1’，其次是T2’，第三是T3’，则TS(T1’) = 1，TS(T2’) = 2, TS(T3’) = 3，一旦开始这三个时间戳就为定值，不再随事务执行而改变。
对于这一协议，假设事务Ti试图锁定X，但无法上锁，因为此时X被其它事务Tj锁定。

Wait-die 等待-死亡策略：该策略是非剥夺式的。如果Ti的时间戳TS(Ti) < TS(Tj), 那么称Ti更老，则Ti可以继续等待。否则Ti直接中止并回滚，并之后重新以之前相同的时间戳启动。该策略可以这么理解：我们到达同一个工具间工作，我是一个性情温和的人，我先到但我后需要，既然现在你正在使用，那我愿意在这等你用完我再用。但如果我后到，我看到你正在用，那我直接选择回家，不浪费时间，下次再来。
Wound-wait 伤害-等待策略：该策略是剥夺式的。如果Ti的时间戳TS(Ti) < TS(Tj), 那么称Ti更老，则直接中止Tj并回滚，Ti抢占其资源，之后以同样的时间戳重新启动Tj。否则Ti继续等待。该策略可以这么理解：我是一个脾气暴躁的人，永远只认先到先得这个道理。如果现在我需要使用，那你必须让给我，你下次再来吧。但要是我后到呢，那我也不甘心，我就在原地等你用完我就用。

让我们来看看在这两种策略下，上面的例子中出现的死锁将如何被预防吧：
在这里插入图片描述

2. 死锁检测

处理死锁的另一种方法是死锁检测，系统检查是否存在死锁状态。如果我们知道事务之间的干扰很小，也就是说，如果不同的事务很少同时访问相同的项目，那么这个解决方案就很有吸引力。如果事务很短且每个事务只锁定少数项目，或者事务负载很轻，就会发生这种情况。另一方面，如果事务很长并且每个事务使用许多项，或者如果事务负载很重，那么使用死锁预防方案可能会比较有利。

一种简单的检测思路便是让系统构建并维护一张等待图，当存在等待时，构建等待边【详见上文对等待图的介绍】，当等待结束，成功获取到锁时，删除这条边。当且仅当检测到图中存在至少一个环时，就检测到死锁状态。
该方法的关键是要确定系统什么时候去维护这张等待图。是定时维护？还是定事务执行的次数维护？周期太短，维护过频将导致过多的开销，降低性能。但周期太长又不能及时检测到死锁。

检测到死锁之后，如何去处理死锁（解除死锁）呢？

通常有两种手段：撤销或超时

a. 撤销

通常我们选择在检测到死锁发生的时候，优先去撤销当前已经执行过的更新次数最少的事务。保留那些已经运行了较长时间的事务。这里如何去制定一个更合理、更公平的撤销策略，诞生了一系列算法，它们被统称为受害者选择算法（victim selection）

b. 超时

另一个处理死锁的简单方案是使用超时。该方法具有开销小、简单等优点，是一种实用的方法。在此方法中，如果事务等待的时间超过系统定义的超时时间，则系统假定事务可能死锁并中止它——不管死锁是否实际存在。

三、饥饿与饿死

当我们使用锁时，可能发生的另一个问题是饥饿，当系统中的其他事务正常地继续时，一个事务在一段较长时间内，一直处于等待阶段，始终不能获取到资源时，就会发生饥饿。

如果锁定项的等待方案不公平，即某些事务的优先级高于其他事务，则可能发生这种情况。如果长时间得不到资源，即使最后得到了资源，执行完毕后已经达不到预期的结果，便被称为饿死。饿死这一现象在CPU进行进程调度时更为常见。

解决饥饿问题的方法

建立一个公平的等待机制。比如使用先到先服务的队列;事务可以按照它们最初请求锁的顺序锁定项目。
等待越久优先级越高。允许某些事务优先于其他事务，但等待的时间越长，事务的优先级就越高，直到它最终获得最高优先级并继续执行。如果算法重复选择与受害者相同的事务，也会因为受害者选择而发生饥饿，从而导致它中止并永远无法完成执行。该算法可以对多次中止的事务使用更高的优先级，以避免这个问题。前面我们讨论过的的等待-死亡和伤害-等待方案都避免了饥饿，因为它们重新启动一个事务时，保留其原始时间戳，因此同一个事务重复中止的可能性很小。