如何避免死鎖

什麼是死鎖，如何避免死鎖？

執行緒a需要資源x，而執行緒b需要資源y，而雙方都掌握有對方所要的資源，這種情況稱為死鎖（deadlock），或死亡擁抱（the deadly embrace）。

在併發程式設計中，死鎖 (deadlock) 是一種十分常見的邏輯錯誤。通過採用正確的程式設計方式，死鎖的發生不難避免。

死鎖的四個必要條件

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

在計算機專業的本科教材中，通常都會介紹死鎖的四個必要條件。這四個條件缺一不可，或者說只要破壞了其中任何乙個條件，死鎖就不可能發生。我們來複習一下，這四個條件是：

互斥（mutual exclusion）：存在這樣一種資源，它在某個時刻只能被分配給乙個執行緒（也稱為執行緒）使用；

持有（hold and wait）：當請求的資源已被占用從而導致執行緒阻塞時，資源占用者不但無需釋放該資源，而且還可以繼續請求更多資源；

不可剝奪（no preemption）：執行緒獲得到的互斥資源不可被強行剝奪，換句話說，只有資源占用者自己才能釋放資源；

環形等待（circular wait）：若干執行緒以不同的次序獲取互斥資源，從而形成環形等待的局面，想象在由多個執行緒組成的環形鏈中，每個執行緒都在等待下乙個執行緒釋放它持有的資源。

不難看出，在死鎖的四個必要條件中，第

二、三和四項條件比較容易消除。通過引入事務機制，往往可以消除第

二、三兩項條件，方法是將所有上鎖操作均作為事務對待，一旦開始上鎖，即確保全部操作均可回退，同時通過鎖管理器檢測死鎖，並剝奪資源（回退事務）。這種做法有時會造成較大開銷，而且也需要對上鎖模式進行較多改動。

消除第四項條件是比較容易且代價較低的辦法。具體來說這種方法約定：上鎖的順序必須一致。具體來說，我們人為地給鎖指定一種類似「水位」的方向性屬性。無論已持有任何鎖，該執行緒所有的上鎖操作，必須按照一致的先後順序從低到高（或從高到低）進行，且在乙個系統中，只允許使用一種先後次序。

請注意，放鎖的順序並不會導致死鎖。也就是說，儘管按照鎖a, 鎖b, 放a, 放b 這樣的順序來進行鎖操作看上去有些怪異，但是只要大家都按先a後b的順序上鎖，便不會導致死鎖。

解決方法：

1 使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務； (細化處理邏輯，執行一段邏輯後便回滾或者提交，然後再執行其它邏輯，直到事物執行完畢提交)

2 設定死鎖超時引數為合理範圍，如：3分鐘-10分種；超過時間，自動放棄本次操作，避免程序懸掛；

3 優化程式，檢查並避免死鎖現象出現；

4 .對所有的指令碼和sp都要仔細測試，在正是版本之前。

5 所有的sp都要有錯誤處理（通過@error）

6 一般不要修改sql server事務的預設級別。不推薦強行加鎖

按同一順序訪問物件

如果所有併發事務按同一順序訪問物件，則發生死鎖的可能性會降低。例如，如果兩個併發事務獲得 supplier 表上的鎖，然後獲得 part 表上的鎖，則在其中乙個事務完成之前，另乙個事務被阻塞在 supplier 表上。第乙個事務提交或回滾後，第二個事務繼續進行。不發生死鎖。將儲存過程用於所有的資料修改可以標準化訪問物件的順序。

避免事務中的使用者互動

避免編寫包含使用者互動的事務，因為執行沒有使用者互動的批處理的速度要遠遠快於使用者手動響應查詢的速度，例如答覆應用程式請求引數的提示。例如，如果事務正在等待使用者輸入，而使用者去吃午餐了或者甚至回家過週末了，則使用者將此事務掛起使之不能完成。這樣將降低系統的吞吐量，因為事務持有的任何鎖只有在事務提交或回滾時才會釋放。即使不出現死鎖的情況，訪問同一資源的其它事務也會被阻塞，等待該事務完成。

保持事務簡短並在乙個批處理中

在同一資料庫中併發執行多個需要長時間執行的事務時通常發生死鎖。事務執行時間越長，其持有排它鎖或更新鎖的時間也就越長，從而堵塞了其它活動並可能導致死鎖。保持事務在乙個批處理中，可以最小化事務的網路通訊往返量，減少完成事務可能的延遲並釋放鎖。

使用低隔離級別

確定事務是否能在更低的隔離級別上執行。執行提交讀允許事務讀取另乙個事務已讀取（未修改）的資料，而不必等待第乙個事務完成。使用較低的隔離級別（例如提交讀）而不使用較高的隔離級別（例如可序列讀）可以縮短持有共享鎖的時間，從而降低了鎖定爭奪。

使用繫結連線

使用繫結連線使同一應用程式所開啟的兩個或多個連線可以相互合作。次級連線所獲得的任何鎖可以象由主連線獲得的鎖那樣持有，反之亦然，因此不會相互阻塞。

如何避免死鎖

如何避免死鎖

如何避免死鎖

如何避免死鎖

相關推薦