deadlocks（死锁）
一种情形，此时执行
程序中两个或多个
线程发生永久堵塞（等待），每个线程都在等待被
死锁
其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。
计算机系统中,如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因
竞争资源不当而产生死锁的现象。 在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。 例如：
事务 A 获取了行 1 的
共享锁。事务 B 获取了行 2 的共享锁。 现在，事务 A 请求行 2 的排他锁，但在事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。 现在，事务 B 请求行 1 的排他锁，但在事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。 事务 B 完成之后事务 A 才能完成，但是事务 B 由事务 A 阻塞。该条件也称为循环依赖关系： 事务 A 依赖于事务 B，事务 B 通过对事务 A 的依赖关系关闭循环。 除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。 Microsoft SQL Server 数据库引擎死锁
监视器定期检查陷入死锁的任务。 如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。 这样，其他任务就可以完成其事务。 对于事务以
死锁
错误终止的
应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。 在应用程序中使用特定编码约定可以减少应用程序导致死锁的机会。 有关详细信息，请参阅将死锁减至最少。 死锁经常与正常阻塞混淆。 事务请求被其他事务锁定的资源的锁时，发出请求的事务一直等到该锁被释放。 默认情况下，除非设置了 LOCK_TIMEOUT，否则 SQL Server 事务不会超时。 因为发出请求的事务未执行任何操作来阻塞拥有锁的事务，所以该事务是被阻塞，而不是陷入了死锁。 最后，拥有锁的事务将完成并释放锁，然后发出请求底事务将获取锁并继续执行。 死锁有时称为抱死。 不只是
关系数据库管理系统，任何多线程系统上都会发生死锁，并且对于数据库对象的锁之外的资源也会发生死锁。 例如，多线程
操作系统中的一个线程要获取一个或多个资源（例如，内存块）。 如果要获取的资源当前为另一线程所拥有，则第一个线程可能必须等待拥有线程释放目标资源。 这就是
死锁
说，对于该特定资源，等待线程依赖于拥有线程。 在数据库引擎实例中，当获取非数据库资源（例如，内存或线程）时，会话会死锁。 在示例中，对于
Part 表锁资源，事务 T1 依赖于事务 T2。 同样，对于
Supplier 表锁资源，事务 T2 依赖于事务 T1。 因为这些依赖关系形成了一个循环，所以在事务 T1 和事务 T2 之间存在死锁。 当表进行了分区并且 ALTER TABLE 的 LOCK_ESCALATION 设置设为 AUTO 时也会发生死锁。 当 LOCK_ESCALATION 设为 AUTO 时，通过允许数据库引擎在 HoBT 级别而不是 TABLE 级别锁定表分区会增加并发情况。 但是，当单独的事务在某个表中持有分区锁并希望在其他事务分区上的某处持有锁时，会导致发生死锁。 通过将 LOCK_ESCALATION 设为 TABLE 可以避免这种类型的死锁，但此设置会因强制某个分区的大量更新以等待某个表锁而减少并发情况。
产生死锁的原因主要是：
（1） 因为
系统资源不足。 （2） 进程运行推进的顺序不合适。 （3） 资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
产生死锁的四个必要条件：
互斥条件（Mutual exclusion）
一个资源每次只能被一个进程使用。
请求与保持条件（占有等待）（Hold and wait） 一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件（不可抢占）（No pre-emption）
进程已获得的资源，在未使用完之前，不能强行剥夺。
循环等待条件（Circular wait）
若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件，只要
系统发生死锁，这些条件必然成立，而只要上述条件之 一不满足，就不会发生死锁。
死锁的解除与预防
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、
进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。
有序资源分配法
这种算法资源按某种规则系统中的所有资源统一编号（例如打印机为1、磁带机为2、磁盘为3、等等），申请时必须以上升的次序。系统要求申请进程： 1、对它所必须使用的而且属于同一类的所有资源，必须一次申请完； 2、在申请不同类资源时，必须按各类设备的编号依次申请。例如：进程PA，使用资源的顺序是R1，R2； 进程PB，使用资源的顺序是R2，R1；若采用动态分配有可能形成环路条件，造成死锁。 采用有序资源分配法：R1的编号为1，R2的编号为2； PA：申请次序应是：R1，R2 PB：申请次序应是：R1，R2 这样就破坏了环路条件，避免了死锁的发生
银行算法
避免死锁算法中最有代表性的算法是Dijkstra E.W 于1968年提出的
银行家算法： 该算法需要检查申请者对资源的最大需求量，如果系统现存的各类资源可以满足申请者的请求，就满足申请者的请求。 这样申请者就可很快完成其计算，然后释放它占用的资源，从而保证了系统中的所有进程都能完成，所以可避免死锁的发生。
死锁排除的方法
1、撤消陷于死锁的全部进程； 2、逐个撤消陷于死锁的进程，直到死锁不存在； 3、从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失。 4、从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态
计算机网络的死锁
死锁是网络中最容易发生的故障之一,即使在网络负荷不很重时也会发生。死锁发生时,一组节点由于没有空闲
缓冲区而元法接收和转发分组,节点之间相互等待,既不能接收分组也不能转发分组,并一直保持这一僵局,严重时甚至导致整个网络的瘫痪。此时,只能靠人工干预来重新启动网络,解除死锁。但重新启动后并未消除引起死锁的隐患,所以可能再次发生死锁。死锁是由于控制技术方面的某些缺陷所引起的,起因通常难以捉摸、难以发现,即使发现,也常常不能立即修复。因此,在各层协议中都必须考虑如何避免死锁的问题。
存储转发死锁及其防止
最常见的死锁是发生在两个节点之间的
直接存储转发死锁。例如,A节点的所有缓冲区装满了等待输出到B节点的分组,而B节点的所有缓冲区也全部装满了等待输出到A节点的分组;此时,A节点不能从B节点接收分组,B节点也不能从A节点接收分组,从而造成两节点间的死锁。这种情况也可能发生在一组节点之间,例如,A节点企图向B节点发送分组、B节点企图向C节点发送分组、而C节点又企图向A节点发送分组,但此时每个节点都无空闲缓冲区用于接收分组,这种情形称做
间接存储转发死锁。当一个节点处于死锁状态时,所有与之相连的链路将被完全拥塞。 一种防止存储转发死锁的方法是,每个节点设置M+1个缓冲区,并以0到M编号。M为通信子网的直径,即从任一源节点到任一目的节点间的最大链路段数。每个源节点仅当其0号缓冲区空时才能接收源端系统来的分组,而此分组仅能转发给1号缓冲区空闲的相邻节点,再由该节点将分组转发给它的2号缓冲区空闲的相邻节点……最后,该分组或者顺利到达目的节点并被递交给目的端系统,或者到了某个节点编号为M的缓冲区中再也转发不下去,此时一定发生了循环,应该将该分组丢弃。由于每个分组都是按照编号递增规则分配缓冲区,所以节点之间不会相互等待空闲缓冲区而发生死锁现象。这种方法的不足之处在于,当某节点虽然有空闲缓冲区,但正巧没有所需要的特定编号的缓冲区时,分组仍要等待,从而造成了缓冲区和链路的浪费。 另一种防止存储转发死锁的方法是,使每个分组上都携带一个全局性的惟一的"时间戳",每个节点要为每条输入链路保留一个特殊的接收缓冲区,而其它缓冲区均可用于存放中转分组。在每条输出链路的队列上分组按时间戳顺序排队。例如,节点A要将分组送到节点B,若B节点没有空闲缓冲区,但正巧有要送到A节点的分组,此时A、B节点可通过特殊的接收缓冲区交换分组;若B节点既没有空闲缓冲区,也没有要送往A节点的分组,B节点只好强行将一个出路方向大致与A节点方向相同的分组与A节点互相交换分组,但此时A节点中的分组必须比B节点中的分组具有更早的时间戳,这样才能保证子网中某个最早的分组不受阻挡地转发到目的地。由此可见,每个分组最终总会成为最早的分组,并总能被一步一步地发送到目的节点,从而避免了死锁现象的发生。
重装死锁及其防止
死锁中比较严重的情况是重装死锁。假设发给一个端系统的报文很长,被源节点拆成若干个分组发送,目的节点要将所有具有相同编号的分组重新装配成报文递交给目的端系统,若目的节点用于重装报文的缓冲区空间有限,而且它无法知道正在接收的报文究竟被拆成多少个分组,此时,就可能发生严重的问题:为了接收更多的分组,该目的节点用完了它的缓冲空间,但它又不能将尚未拼装完整的报文递送给目的端系统,而邻节点仍在不断地向它传送分组,但它却无法接收。这样,经过多次尝试后,邻节点就会绕道从其它途径再向该目的节点传送分组,但该目的节点已被死锁,其周边区域也由此发生了拥塞。
避免重装死锁发生的方法
下面几种方法可用以避免重装死锁的发生: ①允许目的节点将不完整的报文递交给目的端系统; ②一个不能完整重装的报文能被检测出来,并要求发送该报文的源端系统重新传送; ③为每个节点配备一个后备缓冲空间,用以暂存不完整的报文。 ①、②两种方法不能很满意地解决重装死锁,因为它们使端系统中的协议复杂化了。一般的设计中,
网络层应该对端系统透明,也即端系统不该考虑诸如报文拆、装之类的事。③方法虽然不涉及端系统,但使每个节点增加了开销。
Sql Server2000支持的表级锁定
HOLDLOCK 持有共享锁，直到整个事务完成，应该在被锁对象不需要时立即释放，等于SERIALIZABLE
事务隔离级别 NOLOCK 语句执行时不发出共享锁，允许脏读 ，等于 READ UNCOMMITTED事务隔离级别 PAGLOCK 在使用一个表锁的地方用多个页锁 READPAST 让sql server跳过任何锁定行，执行事务，适用于READ UNCOMMITTED事务隔离级别只跳过RID锁，不跳过页，区域和表锁 ROWLOCK 强制使用行锁 TABLOCKX 强制使用独占表级锁，这个锁在事务期间阻止任何其他事务使用这个表 UPLOCK 强制在读表时使用更新而不用共享锁
扫一扫
1117
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
