資料庫死鎖解決方案

如果事務t1封鎖了資料r，事務t2又請求封鎖r，於是t2等待。t3也請求封鎖r，當t1釋放了r上的封鎖之後系統首先批准了t3的請求，t2仍然等待。然後t4又請求封鎖r，當t3釋放了r上的封鎖之後系統又批准了t4的請求，...，t2有可能永遠等待，這就是活鎖的情形。 

避免活鎖的簡單方法是採用先來先服務的策略。

二、死鎖

如果事務t1封鎖了資料r1，t2封鎖了資料r2，然後t1又請求封鎖r2，因t2已封鎖了r2，於是t1等待t2釋放r2上的鎖。接著t2又申請封鎖r1，因t1已封鎖了r1，t2也只能等待t1釋放r1上的鎖。這樣就出現了t1在等待t2，而t2又在等待t1的局面，t1和t2兩個事務永遠不能結束，形成死鎖。

1. 死鎖的預防

在資料庫中，產生死鎖的原因是兩個或多個事務都已封鎖了一些資料物件，然後又都請求對已為其他事務封鎖的資料物件加鎖，從而出現死等待。防止死鎖的發生其實就是要破壞產生死鎖的條件。預防死鎖通常有兩種方法：

① 一次封鎖法 

一次封鎖法要求每個事務必須一次將所有要使用的資料全部加鎖，否則就不能繼續執行。

一次封鎖法雖然可以有效地防止死鎖的發生，但也存在問題，一次就將以後要用到的全部資料加鎖，勢必擴大了封鎖的範圍，從而降低了系統的併發度。

② 順序封鎖法 

順序封鎖法是預先對資料物件規定乙個封鎖順序，所有事務都按這個順序實行封鎖。

順序封鎖法可以有效地防止死鎖，但也同樣存在問題。事務的封鎖請求可以隨著事務的執行而動態地決定，很難事先確定每乙個事務要封鎖哪些物件，因此也就很難按規定的順序去施加封鎖。

可見，在作業系統中廣為採用的預防死鎖的策略並不很適合資料庫的特點，因此dbms在解決死鎖的問題上普遍採用的是診斷並解除死鎖的方法。

2. 死鎖的診斷與解除

① 超時法

如果乙個事務的等待時間超過了規定的時限，就認為發生了死鎖。超時法實現簡單，但其不足也很明顯。一是有可能誤判死鎖，事務因為其他原因使等待時間超過時限，系統會誤認為發生了死鎖。二是時限若設定得太長，死鎖發生後不能及時發現。

② 等待圖法

事務等待圖是乙個有向圖g=(t,u)。 t為結點的集合，每個結點表示正執行的事務；u為邊的集合，每條邊表示事務等待的情況。若t1等待t2,則t1、t2之間劃一條有向邊，從t1指向t2。事務等待圖動態地反映了所有事務的等待情況。併發控制子系統周期性地（比如每隔1分鐘）檢測事務等待圖，如果發現圖中存在迴路，則表示系統中出現了死鎖。

避免死鎖演算法中最有代表性的演算法是dijkstra e.w 於2023年提出的銀行家演算法：

該演算法需要檢查申請者對資源的最大需求量，如果系統現存的各類資源可以滿足申請者的請求，就滿足申請者的請求。