【基本概念】
死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永在互相等待的进远程称为死锁进程。
【产生的条件】
产生死锁的四个必要条件:
(1) 互斥条件:一个资源每次只能被一个进程使用。
(2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
(3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
(4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
【死锁的场景】
一、
进程T1占有资源R1,请求R2资源。
进程T2占有资源R2,请求R1资源。
两者造成僵持,都不能执行,只要有一个可以正常执行,死锁问题就得到了解决。
二、
循环等待场景
计算机网络的死锁
死锁是网络中最容易发生的故障之一,即使在网络负荷不很重时也会发生。死锁发生时,一组节点由于没有空闲缓冲区而无法接收和转发分组,节点之间相互等待,既不能接收分组也不能转发分组,并一直保持这一僵局,严重时甚至导致整个网络的瘫痪。此时,只能靠人工干预来重新启动网络,解除死锁。但重新启动后并未消除引起死锁的隐患,所以可能再次发生死锁。死锁是由于控制技术方面的某些缺陷所引起的,起因通常难以捉摸、难以发现,即使发现,也常常不能立即修复。因此,在各层协议中都必须考虑如何避免死锁的问题。
存储转发死锁及其防止
最常见的死锁是发生在两个节点之间的直接存储转发死锁。例如,A节点的所有缓冲区装满了等待输出到B节点的分组,而B节点的所有缓冲区也全部装满了等待输出到A节点的分组;此时,A节点不能从B节点接收分组,B节点也不能从A节点接收分组,从而造成两节点间的死锁。这种情况也可能发生在一组节点之间,例如,A节点企图向B节点发送分组、B节点企图向C节点发送分组、而C节点又企图向A节点发送分组,但此时每个节点都无空闲缓冲区用于接收分组,这种情形称做间接存储转发死锁。当一个节点处于死锁状态时,所有与之相连的链路将被完全拥塞。
死锁中比较严重的情况是重装死锁。假设发给一个端系统的报文很长,被源节点拆成若干个分组发送,目的节点要将所有具有相同编号的分组重新装配成报文递交给目的端系统,若目的节点用于重装报文的缓冲区空间有限,而且它无法知道正在接收的报文究竟被拆成多少个分组,此时,就可能发生严重的问题:为了接收更多的分组,该目的节点用完了它的缓冲空间,但它又不能将尚未拼装完整的报文递送给目的端系统,而邻节点仍在不断地向它传送分组,但它却无法接收。这样,经过多次尝试后,邻节点就会绕道从其它途径再向该目的节点传送分组,但该目的节点已被死锁,其周边区域也由此发生了拥塞。
【解决方法】
预防、避免、检测
理解了产生死锁的四个必要条件,就可以最大可能地避免、预防和解除死锁。所以,在系统设计、进程调度等方面注意如何不让这四个必要条件成立,如何确定资源的合理分配算法,避免进程永久占据系统资源。此外,也要防止进程在处于等待状态的情况下占用资源。因此,对资源的分配要给予合理的规划。
除了预防,还有更好的解决方法,那就是可以添加虚拟内存,这样电脑就不用担心进程资源的利用率不足了,这也是一个没有办法的办法。
再者撤销或挂起一些进程,以便回收一些资源,再将这些资源分配给已处于阻塞状态的进程,使之转为就绪状态,以继续运行。死锁的检测和解除措施,有可能使系统获得较好的资源利用率和吞吐量,但在实现上难度也最大。
最后可以破坏互斥条件有比较严格的限制,在SQL Server中,如果业务逻辑上允许脏读,则可以通过将隔离等级改为未提交读或使用索引提示。这样使得读取不用加S锁,从而避免了和其它查询所加的与S锁不兼容的锁互斥,进而减少了死锁出现的概率。
【综合的死锁策略】
在系统中所配置的不可剥夺资源,由于它们的数量不能满足诸
*把资源分成几组不同的资源类。
*为预防在资源类之间由于循环等待产生死锁,可使用前面定义的线性排序策略。
*在一个资源类中,使用该类最适合的算法。
作为该技术的一个例子,考虑下列资源类:
*可交换空间:在进程交换中所使用的外存中的存储块。
可采用以下策略:
通过要求一次性分配所有请求的资源来预防死锁,就像占有且等待预防策略一样。
如果知道最大存储需求,则这个策略是合理的。死锁避免也是可能的。
*进程资源:可分配的设备,如磁带设备和文件。
可采用的策略:
对这类资源,死锁避免策略常常是很有效的,这是因为进程可以事先声明它们将需要的这类资源。采用资源排序的预防策略也是可能的。
*内存:可以按页或按段分配给进程。
对于内存,基于抢占的预防是最适合的策略。当一个进程被抢占后,它仅仅被换到外存,释放空间以解决死锁。
内部资源:
诸如I/O通道.
可以使用基于资源排序的预防策略。