死锁的产生及检测

先介绍一下锁的分类 ：

锁的类别有两种分法：

（1）从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁

a. 共享 (S) ：读锁，用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。

b. 更新 (U) ：(介于共享和排它锁之间），可以让其他程序在不加锁的条件下读，但本程序可以随时更改。

读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。

更新锁的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。当我们用更新锁来读取记录时可以对取到的记录加上更新锁，从而加上锁的记录在其它的线程中是不能更改的只能等本线程的事务结束后才能更改，

如下示例：

BEGIN TRANSACTION --开始一个事务
SELECT Qty
 FROM myTable WITH (UPDLOCK)
 WHERE Id in (1,2,3)

 UPDATE myTable SET Qty = Qty - A.Qty
 FROM myTable  AS A 
 INNER JOIN  @_Table AS B ON A.ID = B.ID

COMMIT TRANSACTION --提交事务

这样在更新时其它的线程或事务在这些语句执行完成前是不能更改ID是１，２，３的记录的．其它的都可以修改和读，１，２，３的只能读，要是修改的话只能等这些语句完成后才能操作.从而保证的数据的修改正确.

c. 排它 (X)：写锁。 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。

意向锁 :用于建立锁的层次结构。
意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。
架构锁 :在执行依赖于表架构的操作时使用。
架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。

共享锁 :共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。

更新锁 :更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。 若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。

排它锁 :排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。

意向锁 :意向锁表示 SQL Server 需要在层次结构中的某些底层资源上获取共享 (S) 锁或排它 (X) 锁。例如，放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享 (S) 锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它 (X) 锁。意向锁可以提高性能，因为 SQL Server 仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。

死锁的定义：

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。

产生死锁的原因主要是：

（1） 因为系统资源不足。
（2） 进程运行推进的顺序不合适。
（3） 资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。

产生死锁的四个必要条件：

（1） 互斥条件(Mutual exclusion)：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

（2） 请求与保持条件(Hold and wait)：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。

（3） 不剥夺条件(No pre-emption):指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。

（4） 循环等待条件(Circular wait)：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

这四个条件是死锁产生的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

避免方法：

1) 预防死锁。
　　通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或者几个，来预防发生死锁。预防死锁是一种较易实现的方法，已被广泛使用。但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。

2) 避免死锁。
　　该方法同样是属于事先预防的策略，但它并不须事先采取各种限制措施去破坏产生死锁的的四个必要条件，而是在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免发生死锁。

3)检测死锁。
　　这种方法并不须事先采取任何限制性措施，也不必检查系统是否已经进入不安全区，此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构，及时地检测出死锁的发生，并精确地确定与死锁有关的进程和资源，然后采取适当措施，从系统中将已发生的死锁清除掉。

4)解除死锁。
　　这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时，须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态，以继续运行。死锁的检测和解除措施，有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。

死锁的解除：

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。
⑴有序资源分配法。
这种算法资源按某种规则系统中的所有资源统一编号（例如打印机为1、磁带机为2、磁盘为3、等等），申请时必须以上升的次序。
采用有序资源分配法：R1的编号为1，R2的编号为2；PA：申请次序应是：R1，R2；PB：申请次序应是：R1，R2；这样就破坏了环路条件，避免了死锁的发生。

⑵银行算法。
避免死锁算法中最有代表性的算法是DijkstraE.W于1968年提出的银行家算法。该算法需要检查申请者对资源的最大需求量，如果系统现存的各类资源可以满足申请者的请求，就满足申请者的请求。这样申请者就可很快完成其计算，然后释放它占用的资源，从而保证了系统中的所有进程都能完成，所以可避免死锁的发生。

死锁排除的方法

撤消陷于死锁的全部进程；逐个撤消陷于死锁的进程，直到死锁不存在；从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失；从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态。死锁是网络中最容易发生的故障之一，即使在网络负荷不很重时也会发生。死锁发生时，一组节点由于没有空闲缓冲区而元法接收和转发分组，节点之间相互等待，既不能接收分组也不能转发分组，并一直保持这一僵局，严重时甚至导致整个网络的瘫痪。 常用的实施方法是撤消或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态以继续运行。
（1）剥夺资源。从其它进程剥压足够数量的资源给死锁进程，以解除死锁状态；
（2）撤消进程。最简单的撤消进程的方法是使全部死锁进程都夭折掉；稍为温和一点的方法是按照某种顺序逐个地撤消进程，直至有足够的资源可用，死锁状态消除为止。