并发控制四（活锁和死锁）

和操作系统一样，封锁的方法可能引起活锁和死锁等问题。

• 活锁

如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待；T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待；然后T4又请求封锁R，当T3释放了R之后系统又批准了T4的请求，T2可能永远都处于等待，这就是活锁。

避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁统一数据对象时，封锁子系统按请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准队列中的第一个事务获得锁。

• 死锁

如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已经封锁了R2，于是T1等待T2释放R2上的锁；接着T2又申请封锁R1，因T1封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1等待T2，T2等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。

数据库中解决死锁主要有两种方法：第一是采取一定的措施来预防死锁的发生，另一种是允许死锁发生，采用一定的手段定期诊断系统中有无死锁，有则解除。

（1）死锁的预防

数据库中，产生死锁的原因是两个或多个事务都已经封锁了一些数据对象，然后又都请求对已经被其他事务封锁的数据对象加锁，从而实现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁有以下两种方法：

一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。虽然这样可以有效地防止死锁的发生，但也存在问题，第一，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度；第二，数据库中数据是不断变化的，原来不要求封锁的数据在执行过程中可能会变成封锁对象，所以很难实现精确地确定每个事务要封锁的数据对象，为此只能扩大封锁范围，将事务在执行过程中可能要用到的数据对象全部加锁，也就进一步降低了并发度。

顺序封锁法：顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实施封锁。例如在B树结构的索引中，可规定封锁的顺序必须是从根节点开始，然后是下一级的子节点，逐级封锁。顺序封锁法虽然可以有效地防止死锁，但也存在问题，第一，数据库系统中封锁的数据对象极多，并且随着数据的插入、删除等操作而不断地变化，要维护这样的资源的封锁顺序非常困难，成本很高；第二，事务的封锁请求可以随着事务的执行而动态地决定，很难实现确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。

（2）死锁的诊断与解除

数据库系统中诊断死锁的方法与操作系统很类似，一般使用超时法或事务等待图法。

超时法：如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显，一是有可能误判死锁，如事务因为其他原因而使等待时间超过时限，系统会误认为发生了死锁；而是时限若设置得太长，死锁发生后不能及时发现。

等待图法：事务等待图是一个有向图G=(T,U)，T为节点的集合，每个节点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2，则在T1、T2之间画一条有向边，从T1指向T2。并发控制子系统周期性地生成事务等待图，并进行检测。如果途中存在回路，则表示系统中出现了死锁。一旦出现了死锁，通常采用的方法是选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有的所有的锁，使其他事务得意继续运行下去。当然，对撤销的事务所执行的数据修改操作必须加以恢复。