死鎖概念以及預防解決方法簡介 多線程上篇（八）

在前面不止一次的提到過死鎖。

所謂死鎖(Deadlock)

是指多個進程在運行過程當中因爭奪資源而形成的一種僵局(DeadlyEmbrace)，當進程處於這種僵持狀態時，若無外力做用，它們都將沒法再向前推動。

死鎖的定義：集合中的每個進程都在等待只能由本集合中的其餘進程才能引起的事件，那麼該組進程是死鎖的。

也就是說集合中的人須要等待本集合中的其餘人來幫忙， 可是，可怕的是全部的人都是這狀態。

引發死鎖的主要緣由是：「須要採用互斥方法訪問的、不能夠被搶佔的資源「。

由於須要互斥，因此就產生了競爭，出現了競爭就會出現等待，可是資源又不可被搶佔，因此可能會被別人一直佔有，那麼就可能無限的等待，這就造成了死鎖。

資源角度

計算機資源能夠從兩個維度進行劃分，重用性以及搶佔性。

不論是可重用資源仍是消耗性資源，他們都不是能夠任意請求的

系統中可重用資源的個數相對來講比較固定，消耗性資源儘管是個數不固定，動態的，可是某瞬間也都是有個數的，因此也不是能夠任意請求的。

因此不論是否可重用，只要有競爭訪問，就可能出現死鎖。

對於不可搶佔資源，一旦被請求了，若是不可以釋放，那麼別人就必需要等待。

可搶佔資源即便被分配，仍舊能夠被搶佔，因此這類資源不會引發死鎖。

因此，從資源的角度看，只須要關注是不是可搶佔資源，若是不可搶佔，那麼就有可能出現死鎖。

資源分配圖

爲了直觀的分析死鎖的狀況，可使用資源分配圖

是一種描述資源申請與分配關係的圖

使用圓圈表示進程，矩形表示資源；

箭頭表示資源的申請與釋放，資源->進程表示分配，進程->資源表示資源申請。

以下圖所示，表示P1得到了R1在等待R2，P2得到了R2 在等待R1

死鎖產生狀況

競爭不可搶佔資源

P1                  P2

wait(R1)         wait(R2)

wait(R2)         wait(R1)

如上所示，進程P1和P2，一個先申請資源R1，一個先申請資源R2，一旦資源R1和R2同時被兩個不一樣的進程得到，將會進入死鎖狀態。

若是一個結束以後，另外一個開始，那麼就不會出現死鎖。

競爭可消耗資源

設有進程P一、P二、P3，有可消耗資源R一、R二、R3

若是以下順序推動

P1:  send(p2, R1);    receive(p3, R3); 

P2:  send(p3, R2);    receive(p1, R1); 

P3:  send(p1, R3);    receive(p2, R2); 

以下圖所示，每一個進程都先生產資源給別人，而後纔會等待別人的資源，每一個人最終都可以得到資源

若是是

P1:  receive(p3, R3);     send(p2, R1);     

P2:  receive(p1, R1);     send(p3, R2);     

P3:  receive(p2, R2);     send(p1, R3);     

全部的人都在等待別人的資源，纔會生產消息，造成了死鎖。

進程推動順序不當

下圖中，橫座標爲進程1，縱座標爲進程2

進程1的活動過程有Request(R1)  Request(R2)   Release(R1)   Release(R2)

進程2的活動過程有Request(R2)  Request(R1)   Release(R2)   Release(R1)

顯然，圖中的陰影區域D，陰影區域的左下角表示進程1申請了資源R1，進程2申請了資源R2，若是此時進程1申請R2或者進程2申請R1或者二者都有，必然會發生死鎖

若是避開這個區域，好比一個進程結束後另外一個開始，1號曲線或者2號曲線，或者進程1釋放了R1後，進程2纔開始申請R2就不會進入死鎖

經過這種活動順序圖，能夠推測出來可能會出現死鎖的時空區域。

《計算機操做系統 第四版》 圖3-14

死鎖必要條件

前面從資源以及場景的角度分析了死鎖，其根本也仍是「須要採用互斥方法訪問的、不能夠被搶佔的資源」。

死鎖造成有四大必要條件，也就是說若是死鎖了必然存在這些。

若是不互斥，你們均可以訪問，就沒可能死鎖；

若是沒有請求和保持，好比一次性分配，若是分配不到等待別人使用後釋放便可，保持和請求必然會致使「拿走了比人須要的，還等待別人」的場景；

若是能夠搶佔，即便已經死鎖，確定會被打破；

若是沒有循環等待，終究會有一個進程會本身完成，完成後便會釋放本身持有的資源，整個系統就會被激活。

因此說，想要處理死鎖，或者說避免死鎖，關鍵點就是這幾個條件，只要條件被打破，就不會存在繼續死鎖下去的可能。

死鎖解決方法

從預防-避免-檢測-解除，對死鎖的防範程度依次減弱，可是對應的資源的利用率依次提升，也就是併發程度依次變高。

預防就像接種疫苗，可能你這輩子都不會接觸到病毒。

避免就是在可能出事情的地方，作一些保障處理，好比發現有些場合人員混亂，全是二手菸，那就不進房間了。

檢測就好像是按期的體檢，沒問題繼續生活，有什麼小問題就去治療一下。

解除就是真的去看病了。

預防死鎖

預防就是事先前的準備，如同疫苗，死鎖的預防一般就是增長限制，破壞必要條件。

破壞「請求和保持」

全部的資源必須一次性分配，或者不分配，這樣可以保障一個進程要麼就等待，要麼就能夠得到所有的資源，而不會出現保持了資源，而後再去請求的可能。

可是很顯然，資源利用率低，併發程度低

好比說有一個任務三個階段，每一個階段一種資源，每一個階段十分鐘，若是一次性分配的話，每一個資源都會有二十分鐘的閒置，極大地浪費。

這種方案能夠進一步優化，分階段處理，而不是一次性，仍是剛纔的示例，每一個階段僅僅申請該階段的資源，使用完畢後，將資源釋放，而後再去獲取下一階段的資源

也就是說須要合理的劃分階段，一個完整任務中的一個子任務（也就是一個階段）一次性分配資源，使用完畢後釋放，再去請求，就不存在保持請求了。

破壞「不可搶佔」

若是資源是可搶佔的，天然就不會死鎖，終究會自動解鎖，若是可以合理的將不可搶佔資源轉換爲「可搶佔」那麼就能夠預防死鎖

當一個進程持有了某些資源後，若是又提出了新的請求，若是該請求並不能知足，那麼他必須釋放已有的資源，也就能夠說是被搶佔了

不過這個思路實現複雜，可能會付出很大的代價，好比打印機開始處理了，你如今要切換，確定不會很容易。

破壞「循環等待」

將資源按照必定的順序進行申請，能夠保證資源的有序性，也就能夠破壞循環等待，正是由於資源的順序很隨意，因此才致使很容易死鎖

好比全部的進程所有都是R1而後R2，就永運不會死鎖

因此能夠採起對系統內資源編號的形式，全部的資源申請必須是從小到大的順序。

如此，就確定不會循環成環。

可是，號碼如何編？到底誰大誰小？要統計下平時資源的申請順序進行編號

而後若是新增長設備？

另外若是有些進程就是跟系統的排序不一樣怎麼辦？

避免死鎖

在死鎖避免方法中，把系統的狀態分爲安全狀態和不安全狀態。

安全狀態就是能夠找到資源分配的有序序列， 各進程能夠順利推動完成。

不安全狀態若是找不到一個合理的資源分配的有序序列，不能保障各進程能夠順利完成，那麼就是不安全。

當系統處於安全狀態時，可避免發生死鎖。反之，當系統處於不安全狀態時，則可能進入到死鎖狀態。

簡言之，避免死鎖就是在資源分配時，藉助於算法對資源分配進行計算評估，至關於風險評估機構。

經典的算法有Dijkstra提出的銀行家算法

死鎖檢測

死鎖的檢測也是藉助於算法進行處理，想要檢測死鎖

首先，系統中必須可以記錄資源的請求和分配記錄，其次須要提供一種算法，經過對請求和分配記錄進行分析，計算出當前的狀態。

死鎖解除

若是檢測出死鎖，那麼必須進行解除，經常使用的解除方式有兩種，搶佔資源和終止進程，本質都是強行將資源奪回到系統中。

終止進程的話最簡單的就是所有終止，將涉及的死鎖進程所有都終止掉，顯然所有終止就好像將一臺工做中的電腦強行重啓同樣，代價很大

因此還能夠逐個終止，直到死鎖解除。

總結

本文對操做系統中死鎖的概念進行了簡單的介紹，不只僅進程有死鎖，線程的運行仍舊也會有死鎖。

多線程編程中也會出現死鎖，在這些場景中，死鎖的概念是相同的---都是同一個集合中的線程都在等待本集合中的線程

對於操做系統對死鎖的處理與解決，對於編程中不無借鑑之處，咱們應該深入理解死鎖造成的條件，纔可以在編程中儘量的避免死鎖。

原文地址:死鎖概念以及預防解決方法簡介 多線程上篇（八）