目录
一、死锁的概念
1.1 什么是死锁
死锁:在并发环境,各进程因竞争资源而造成的一种互相等待对方手里的资源,导致各进程都阻塞,都无法向前推进的现象。
举个例子,在哲学家进餐问题中,如果5位哲学家进程并发执行,都拿起了左手边的筷子。每位哲学家都在等待自己右边的人放下筷子,这些哲学家进程因等待筷子资源而被阻塞,即发生“死锁”。
发生死锁后若无外力干涉,这些进程都无法向前推进。
1.2 进程死锁、饥饿、死循环的区别
死锁:各进程互相等待对方手里的资源,导致各进程都阻塞。
饥饿:由于长期得不到想要的资源,某进程无法向前推进的现象。如:在短进程优先(SPF)算法中,若有源源不断的短进程到来,则长进程将一直得不到处理机,从而发生长进程「饥饿」。
死循环:某进程执行过程中一直跳不出某个循环的现象。有时是因为程序逻辑bug导致,有时是程序员故意设计。
相同点
- 都是进程无法顺利向前推进的现象。(故意设计的死循环除外)
区别
- 死锁是「循环等待对方手里的资源」导致的,因此如果有死锁现象,那么至少有两个或两个以上的进程同时发生死锁。发生死锁的进程一定是处于「阻塞态」。
- 可能只有一个进程发生饥饿。发生饥饿的进程可能是「阻塞态」(如长期得不到需要的I/O设备),也可能是「就绪态」(长期得不到处理机)。
- 可能只有一个进程发生死循环。死循环的进程可能在「运行态」(上处理机运行),只不过无法像期待的那样顺利推进。
- 死锁和饥饿问题是由于操作系统分配资源的策略不合理导致的,而死循环是由代码逻辑的错误导致的。
- 死锁和饥饿是管理者(操作系统)的问题,死循环是被管理者(程序员)的问题。
1.3 死锁产生的必要条件
产生死锁必须同时满足四个条件(任一条件不成立,都不会死锁):
-
互斥条件:只有对必须互斥使用的资源的争抢才会导致死锁。(如:哲学家的筷子、打印机设备)
像内存、扬声器这中可以同时让多个进程使用的资源是不会导致死锁的。(因为进程不用阻塞等待资源)
-
不剥夺条件:进程所获得的资源在为未使用完之前,不能由其他进程强行夺走,只能主动释放。
如:哲学家不能抢走其他哲学家的筷子,如果能抢走就不会导致死锁,可以顺利进餐了。
-
请求和保持条件:进程已经保持了至少一个资源,但又提出了新的资源请求,而该进程又被其他进程占有,此时请求进程被阻塞,但又对自己已有的资源保持不放。
-
循环等待条件:存在一种进程资源的循环等待链,链中的每一个进程已获得的资源同时被下一个进程请求。
tips:
-
发生死锁时一定有循环等待,但是发生循环等待时未必死锁。(循环等待是死锁的必要不充分条件)
-
因为如果同类资源数大于1,则即使有循环等待,也未必死锁。但如果每类资源只有一个,那循环等待就是死锁的充分必要条件了。
1.4 什么时候会发生死锁
对不可剥夺资源的不合理分配,可能导致死锁。
大致有以下三种情况:
-
对系统资源的竞争。各进程对「不可剥夺的资源」(打印机)的竞争可能引起死锁,对「可剥夺的资源」(CPU)的竞争是不会引起死锁的。
-
进程推进顺序非法。请求和释放资源的顺序不当,同样会导致死锁。如,并发执行的进程P1、P2分别申请并占有了资源R1、R2,之后进程P1又申请资源R2,进程P2又申请资源R1,两者会因为申请的资源被对方占有而阻塞,发生死锁。
-
信号量的使用不当也会造成死锁。如,生产者-消费者问题中,如果实现互斥的P操作在实现同步的P操作之前,就有可能导致死锁。因为如果先进行互斥P操作,那么之后可能在等待同步P操作完成才可执行;而同步P操作又要等待互斥P操作才可进行同步操作,就发生了死锁。所以,先同步P操作再互斥P操作。
ps:可以把互斥信号量、同步信号量也看做是一种抽象的系统资源。
1.5 死锁的处理策略
- 预防死锁。破坏死锁产生的四个必要条件中的一个或几个。
- 避免死锁。用某种方法防止系统进入不安全状态,从而避免死锁(银行家算法)。
- 死锁的检测和解除。允许死锁的发生,不过操作系统会负责检测出死锁的发生,然后才去某种措施解除死锁。
二、死锁的处理策略——预防死锁
预防死锁,就是破坏死锁产生的四个必要条件中的一个或几个。
这四个必要条件是:互斥条件、不剥夺条件、请求和保持条件、循环等待条件
2.1 破坏互斥条件
互斥条件:只有对必须互斥使用的资源的争抢才会导致死锁。
如果把只能互斥使用的资源改造为允许共享使用,则系统不会进入死锁状态。比如:SPOOLing技术。操作系统可以采用SPOOLing技术,把独占设备在逻辑上改造成共享设备。如打印机的例子:
- 打印机是互斥使用的资源,进程1访问打印机后,如果进程2访问打印机将阻塞。
- 为破坏互斥条件,引入SPOOLing技术,在各进程和打印机间设立一个中间件,各进程将打印信息交给中间件后就继续往下执行了,所以不会阻塞。中间件根据顺序将各进程打印信息交于打印机打印,类似于队列。
缺点:并不是所有的资源都可以改造成可共享的资源。并且为了系统安全,很多地方还必须保护这种互斥性。因为,很多时候都无法破坏互斥条件。
2.2 破坏不剥夺条件
不剥夺条件:进程所获得的资源在未使用完之前,不能用由其他进程强行夺走,只能主动释放。
破坏不剥夺条件:
(1)方案一:「资源不足,主动放弃」。当某个进程请求新的资源得不到满足时,它必须立即释放保持的所有资源,待以后需要时再重新申请。也就是说,即使某些资源尚未使用完,也需要主动释放,从而破坏了不可剥夺条件。
(2)方案二:「强行剥夺」。当某个进程需要的资源被其他进程所占有的时候,可以由操作系统协助,将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级(比如:剥夺调度方式,就是将处理机资源强行剥夺给优先级更高的进程使用)。
缺点:
- 实现起来比较复杂。
- 释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用与易保存和恢复状态的资源,如CPU。
- 反复地申请和释放资源会增加系统开销,降低系统吞吐量。
- 若采用方案一,意味着只要暂时得不到某个资源,之前获得的那些资源都需要放弃,以后再重新申请。如果一直发生这样的情况,就会导致进程饥饿。
2.3 破坏请求和保持条件
请求和保持条件:进程已经保持了至少一个资源,但是又提出了新的资源请求,而该资源又被其他进程占有,此时请求进程被阻塞,但是又对自己已有的资源保持不放。
方法:可以采用静态分配方法,即进程在运行前一次申请完它所需的全部资源,在它的资源未满足前,不让它投入运行。一旦运行后,这些资源就一直归它所有,该进程就不会再请求别的任何资源了。
缺点:
-
有些资源可能只需要占用很短的时间,因此如果进程的整个运行期间都一直保持着所有资源,就会造成严重的资源浪费,资源利用率很低。
-
可能导致饥饿。比如,A进程需要资源1、B进程需要资源2、C进程需要资源1和2。开始时,A、B分别占用资源1和2,C进程等待;这时候来了一堆类似于A和B的进程,那么A和B结束后这些资源由被他们占用,C进程一直得不到资源1和2而发生饥饿。
2.4 破坏循环等待条件
循环等待条件:存在一种进程资源的循环等待链,链中的每一个进程已获得的资源同时被下一个进程所请求。
方法:顺序资源分配法,首先给系统中的资源编号,规定每个进程必须按编号递增的顺序请求资源,同类资源(即编号相同的资源)一次申请完。
原理分析:一个进程只有占有已有小编号的资源时,才有资格申请更大编号的资源。按此规则,已持有大编号资源的进程不可能逆向地回来申请小编号的资源,从而就不会产生循环等待的现象。
所以说,在任何时刻,总有一个进程拥有的资源编号是最大的,那这个进程申请之后的资源必然畅通无阻。因此,不可能出现所有进程都阻塞的死锁现象。
缺点:
- 不方便增加新的设备,因为可能需要重新分配所有的编号。
- 进程实际使用资源的顺序可能和编号递增顺序不一致,会导致资源浪费。
- 必须按规定次序申请资源,用户编程麻烦。
三、死锁的处理策略——避免死锁
3.1 安全序列、不安全状态、死锁的联系
安全序列:如果系统按照这种序列分配资源,则每个进程都能顺利完成。只有找到一个安全系列(安全系列可能有多个),系统就是安全状态。
不安全状态:如果分配了资源之后,系统找不到任何一个安全系列,系统就进入了不安全状态。也就说,进入了不安全状态,之后可能所有的进程都无法顺利地执行下去。
ps:当然,如果有系统提前归还了一些资源,还是有可能重新回到安全状态,但是在分配资源之前总是要考虑最坏情况。
如果系统处于安全状态,一定不会发生死锁;如果系统进入不安全状态,可能发生死锁。即处于安全状态不一定发生了死锁,但是发生了死锁时一定在不安全状态。
因此可以在资源分配之前预先判断这次分配是否会导致系统进入不安全状态,以此决定是否答应资源分配请求。这也是「银行家算法」的核心思想。
3.2 如何避免系统进入不安全状态——银行家算法
银行家算法是荷兰学者Dijkstra为银行系统设计的,以确保银行在发放现金贷款时,不会发生不能满足所有用户需要的情况。后来该算法用于操作系统,避免死锁。
银行家算法步骤:
- 检查此次申请是否超过了之前声明的最大需求数
- 检查此时系统剩余的可用资源是否还能满足这次请求
- 试探着分配,更改各数据结构
- 用安全性算法检查此时分配是否导致系统进入不安全状态。
安全性算法:检查当前的剩余可用资源是否能满足某个进程的最大需求,如果可以,就把该进程加入安全序列,并把该进程持有的资源全部回收。
例子
举个例子:系统中有5个进程P0 ~ P4,3种资源R0~R4,初始数量为(10, 5, 7),某时刻各进程分配如下:
进程 | 最大需求 | 已分配 | 还需分配 |
---|---|---|---|
P0 | (7, 5, 3) | (0, 1, 0) | (7, 4, 3) |
P1 | (3, 2, 2) | (2, 0, 0) | (1, 2, 2) |
P2 | (9, 0, 2) | (3, 0, 2) | (6, 0, 0) |
P3 | (2, 2, 2) | (2, 1, 1) | (0, 1, 1) |
P4 | (4, 3, 3) | (0, 0, 2) | (4, 3, 1) |
已分配(7, 2, 5)资源,还剩(3, 3, 2)资源。当前处于是安全状态的,为何:
- 还剩(3, 3, 2)资源,可以分配给P1、而P3。P1、P3运行结束后收回资源,剩余资源:(7, 4, 3)。
- 还剩(7, 4, 3)资源,可以分配给P0、P2、P4。等P0、P2、P4结束后回收所有资源。
判断是否处于安全状态,使用安全性算法检测即可,只要满足一种安全序列就处于安全状态。
假如这时候,P4请求分配资源(1, 2, 1),小于剩余需要分配资源和剩余系统资源,试探着分配资源,剩余分配资源如下:
进程 | 最大需求 | 已分配 | 还需分配 |
---|---|---|---|
P0 | (7, 5, 3) | (0, 1, 0) | (7, 4, 3) |
P1 | (3, 2, 2) | (2, 0, 0) | (1, 2, 2) |
P2 | (9, 0, 2) | (3, 0, 2) | (6, 0, 0) |
P3 | (2, 2, 2) | (2, 1, 1) | (0, 1, 1) |
P4 | (4, 3, 3) | (1, 2, 3) | (3, 1, 0) |
- 这时剩余资源为(2, 1, 1),分配给P3,P3结束。
- 剩余(4, 2, 2),分配给P1、P4,P1、P4结束。
- 剩余(7, 4, 5),分配给P0、P2,P0、P2结束。所有线程结束,不死锁。
所以,P4的请求并不会导致不安全状态,同意P4的请求。
四、死锁的处理策略——检测和解除
如果不采用预防死锁和避免死锁的方法,系统可能发生死锁。在这种情况下,系统应该提供两种算法:
- 死锁检测算法:用于检测系统状态,以确定系统中是否发生了死锁。
- 死锁解除算法:当认定系统中已经发生了死锁,利用该算法可将系统从死锁状态中解脱出来。
4.1 死锁的检测
系统是否发生死锁检测,需要(1)某种数据结构(资源分配图)来保存资源请求和分配信息。(2)一种算法利用上述信息检测系统是否进入死锁状态。
将进程和资源用资源分配图表示,找出一个不阻塞的进程,该进程在用完资源后系统回收资源,某个进程就可能开始运行,某个进程运行结束后系统回收资源,下个进程又可以运行,如此往复。
如果最终所有进程都结束,对于资源分配来说就是能消除所有的边,就没有发生死锁;如果不能消除所有的边就发生了死锁。最终还连着边的进程就是死锁进程。
死锁定理:如果某时刻系统的资源分配图是不可完全简化的,那么此时系统死锁。
4.2 死锁的解除
解决死锁的主要方法有以下三种:
- 资源剥夺法:挂起(暂时放到外存上)某些死锁进程,并抢占它的资源,将这些资源分配给其他的死锁进程。但是应防止被挂起的进程长时间得不到资源而饥饿。
- 撤销进程法(终止进程法):强制撤销部分、甚至全部死锁进程,并剥夺这些进程的资源。这种方式的优点是实现简单,但是付出的代价可能会很大。因为有些进程可能已经运行很久了,接近结束了,一旦终止可谓功亏一篑。
- 进程回退法:让一个或多个死锁进程回退到足以避免死锁的地步。这就要求系统要记录进程的历史信息,设置还原点。
操作哪个进程很重要:
- 进程优先级。优先级低的进程进行剥夺、撤销、回退等操作。
- 已经执行很长时间的进程不可轻易撤销。
- 进程完成还有多长时间。
- 进程已经占用了多少资源。占用了很多资源的进程不易撤销。
- 进程是交互式还是批处理式。用户体验很重要,优先保证交互式进程好好运行。