您好,登錄后才能下訂單哦!
這篇文章給大家介紹如何將deadlock減至最少,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
盡管死鎖不能完全避免,但遵守特定的編碼慣例可以將發生死鎖的機會降至最低。將死鎖減至最少可以增加事務的吞吐量并減少系統開銷,因為只有很少的事務:
回滾,撤消事務執行的所有工作。
由于死鎖時回滾而由應用程序重新提交。
下列方法有助于將死鎖減至最少:
按同一順序訪問對象。
避免事務中的用戶交互。
保持事務簡短并處于一個批處理中。
使用較低的隔離級別。
使用基于行版本控制的隔離級別。
將READ_COMMITTED_SNAPSHOT 數據庫選項設為 ON,使得已提交讀事務使用行版本控制。
使用快照隔離。
使用綁定連接。
按同一順序訪問對象
如果所有并發事務按同一順序訪問對象,則發生死鎖的可能性會降低。例如,如果兩個并發事務先獲取 Supplier 表上的鎖,然后獲取 Part 表上的鎖,則在其中一個事務完成之前,另一個事務將在 Supplier 表上被阻塞。當第一個事務提交或回滾之后,第二個事務將繼續執行,這樣就不會發生死鎖。將存儲過程用于所有數據修改可以使對象的訪問順序標準化。
避免事務中的用戶交互
避免編寫包含用戶交互的事務,因為沒有用戶干預的批處理的運行速度遠快于用戶必須手動響應查詢時的速度(例如回復輸入應用程序請求的參數的提示)。例如,如果事務正在等待用戶輸入,而用戶去吃午餐或甚至回家過周末了,則用戶就耽誤了事務的完成。這將降低系統的吞吐量,因為事務持有的任何鎖只有在事務提交或回滾后才會釋放。即使不出現死鎖的情況,在占用資源的事務完成之前,訪問同一資源的其他事務也會被阻塞。
保持事務簡短并處于一個批處理中
在同一數據庫中并發執行多個需要長時間運行的事務時通常會發生死鎖。事務的運行時間越長,它持有排他鎖或更新鎖的時間也就越長,從而會阻塞其他活動并可能導致死鎖。
保持事務處于一個批處理中可以最小化事務中的網絡通信往返量,減少完成事務和釋放鎖可能遭遇的延遲。
使用較低的隔離級別
確定事務是否能在較低的隔離級別上運行。實現已提交讀允許事務讀取另一個事務已讀取(未修改)的數據,而不必等待第一個事務完成。使用較低的隔離級別(例如已提交讀)比使用較高的隔離級別(例如可序列化)持有共享鎖的時間更短。這樣就減少了鎖爭用。
使用基于行版本控制的隔離級別
如果將 READ_COMMITTED_SNAPSHOT 數據庫選項設置為 ON,則在已提交讀隔離級別下運行的事務在讀操作期間將使用行版本控制而不是共享鎖。
注意: |
---|
某些應用程序依賴于已提交讀隔離的鎖定和阻塞行為。對于這些應用程序,要啟用此選項必須進行一些更改。
|
快照隔離也使用行版本控制,該級別在讀操作期間不使用共享鎖。必須將 ALLOW_SNAPSHOT_ISOLATION 數據庫選項設置為 ON,事務才能在快照隔離下運行。
實現這些隔離級別可使得在讀寫操作之間發生死鎖的可能性降至最低。
使用綁定連接
使用綁定連接,同一應用程序打開的兩個或多個連接可以相互合作。可以像主連接獲取的鎖那樣持有次級連接獲取的任何鎖,反之亦然。這樣它們就不會互相阻塞。
關于如何將deadlock減至最少就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。