資料庫事務死鎖

最近面試被問的比較多的就是死鎖。。(記錄一下吧

死鎖產生的條件

死鎖發生的條件 - 互斥條件：就是乙個資源只能有乙個程序占有，不可以被兩個或者多個程序占有 - 不可搶占條件：程序已經獲得的資源在未使用之前，不可被搶占，只能在使用完之後自己釋放 - 占有申請條件：程序自己已經至少保持乙個資源，又請求其他資源，但是這個資源被其他程序占有，而且又不釋放自己已經占有的資源

- 迴圈等待條件：發生死鎖時，必定會形成乙個程序一一資源的環路。程序集合中，p1請求p2占有的資源，p2請求p3占有的資源，p3請求p1占有的資源

出現的原因

系統資源不足

程序允許推薦順序不當

資源分配不當

所謂死鎖，是指各併發程序彼此互相等待對方所擁有的資源，且這些併發程序在得到對方的資源之前不會釋放自己所擁有的資源。從而造成大家都想得到資源而又得不到資源，各併發程序不能繼續向前推進的狀態。

面試時候的回答

預防死鎖

盡量避免使用多個鎖，並且只有需要時才持有鎖。否則，巢狀的synchronized或者lock非常容易出問題。

使用帶超時的方法，為程式帶來更多的可控性。

死鎖與事務的聯絡

死鎖是兩個或多個事務再同一資源相互占用，並請求鎖定對方占用的資源，從而導致惡性迴圈的現象。

假設如下事務：

事務1

start transaction;
update stockprice set colse=45.50 where stock_id=4 and date=
'2002-05-01'
;update stockprice set colse=19.80 where stock_id=3 and date=
'2002-05-02'
;commit;

事務2

start transaction;
update stockprice set high=20.12 where stock_id=3 and date=
'2002-05-02'
;update stockprice set high=47.20 where stock_id=4 and date=
'2002-05-02'
;commit;

如果湊巧，兩個事務都執行了第一條update語句，更新了一行資料，同時鎖定了該行資料，接著每個事務都嘗試去執行第二條update語句，卻發現該行已經被對方鎖死，然後都在等待對方釋放鎖，同時又互相持有對方需要的鎖，則陷入死迴圈。

為了解決這種問題，資料庫系統實現了各種死鎖檢測和超時機制。一般會在檢測到死鎖後立即返回乙個錯誤。

死鎖的出現有時候是由於儲存引擎導致的，而有的則是業務中真正的資料衝突，而且基本無法避免。死鎖發生後只有回滾其中的乙個事務才能打破死鎖。所以程式設計的時候必須考慮如何處理死鎖。

mysql的innodb儲存引擎，使用redo log保證了事務的永續性

當事務提交時，必須先將事務的所有日誌寫入日誌檔案進行持久化，就是我們常說的wal(write ahead log)機制，這樣才能保證斷電或宕機等情況發生後，已提交的事務不會丟失，這個能力稱為crash-safe

redo log包括兩部分，重做日誌緩衝(redo log buffer)和重做日誌檔案(redo log file)，前者是易失的快取，後者是持久化的檔案。

舉乙個事務的例子:

undo log 保證了事務的原子性

在對資料庫進行修改時，innodb引擎除了會產生redo log，還會產生undo log。innodb實現回滾，靠的是undo log：當事務對資料庫進行修改時，innodb會生成對應的undo log；如果事務執行失敗導致事務需要回滾，就利用undo log中的資訊將資料回滾到修改之前的樣子。

redo log恢復事務導致的資料頁的修改，而undo log是一種邏輯日誌(資料記錄)

undo log還有另外一種重要作用，就是用於mvcc中，進行多版本控制，也就是實現事務隔離性的基礎，當使用者讀取一行記錄時，如果這個記錄已經被其他事務占用，那麼當前事務就可以通過undo讀取之前的新版本資訊，用來實現非鎖定讀取，就是「快照讀」

事務的acid性質不是完全正交的，尤其是一致性，我們可以認為原子性，永續性和隔離性都是為了實現事務的一致性。當然，這裡的一致性是指資料庫層面的事務一致性。

應用層面: 給轉帳者扣錢，沒給接收者加錢，那麼這個不一致跟事務的不一致是沒用關係的，需要開發人員自己做業務邏輯一致性的保證。

資料庫事務死鎖

資料庫系列資料庫事務鎖死鎖

資料庫死鎖

資料庫死鎖

資料庫事務 死鎖

資料庫系列 資料庫事務 鎖 死鎖

資料庫死鎖

資料庫死鎖

相關推薦

資料庫事務死鎖

資料庫系列資料庫事務鎖死鎖