避免死鎖的方法有哪些?

1、避免給一個(gè)鎖嵌套上鎖，在持有一個(gè)鎖的時(shí)候，不要再給這個(gè)鎖上鎖。如果使用多個(gè)鎖，使用std::lock。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供寶雞網(wǎng)站建設(shè)、寶雞做網(wǎng)站、寶雞網(wǎng)站設(shè)計(jì)、寶雞網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、寶雞企業(yè)網(wǎng)站模板建站服務(wù)，十載寶雞做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

2、在持有鎖時(shí)，不要調(diào)用別人提供的函數(shù)，因?yàn)槟悴磺宄e人的代碼怎么實(shí)現(xiàn)的，不知道它是不是在使用鎖。

3、給多個(gè)鎖上鎖時(shí)，固定順序。如果在給多個(gè)所上鎖，并且無法使用std::lock，最好的做法就是在每一個(gè)線程中，都按照同樣的順序。

4、分層次來使用鎖，把程序分成幾個(gè)層次。區(qū)分每個(gè)層次中使用的鎖，當(dāng)一個(gè)線程已經(jīng)持有更低層次的鎖時(shí)，不允許使用高層次的鎖。可以在程序運(yùn)行時(shí)給不同的鎖加上層次號，記錄每個(gè)線程持有的鎖。

擴(kuò)展資料：

解決方法

在系統(tǒng)中已經(jīng)出現(xiàn)死鎖后，應(yīng)該及時(shí)檢測到死鎖的發(fā)生，并采取適當(dāng)?shù)拇胧﹣斫獬梨i。

死鎖預(yù)防。

這是一種較簡單和直觀的事先預(yù)防的方法。方法是通過設(shè)置某些限制條件，去破壞產(chǎn)生死鎖的四個(gè)必要條件中的一個(gè)或者幾個(gè)，來預(yù)防發(fā)生死鎖。預(yù)防死鎖是一種較易實(shí)現(xiàn)的方法，已被廣泛使用。但是由于所施加的限制條件往往太嚴(yán)格，可能會(huì)導(dǎo)致系統(tǒng)資源利用率和系統(tǒng)吞吐量降低。

死鎖避免。

系統(tǒng)對進(jìn)程發(fā)出的每一個(gè)系統(tǒng)能夠滿足的資源申請進(jìn)行動(dòng)態(tài)檢查，并根據(jù)檢查結(jié)果決定是否分配資源；如果分配后系統(tǒng)可能發(fā)生死鎖，則不予分配，否則予以分配。這是一種保證系統(tǒng)不進(jìn)入死鎖狀態(tài)的動(dòng)態(tài)策略。

死鎖檢測和解除。

先檢測：這種方法并不須事先采取任何限制性措施，也不必檢查系統(tǒng)是否已經(jīng)進(jìn)入不安全區(qū)，此方法允許系統(tǒng)在運(yùn)行過程中發(fā)生死鎖。但可通過系統(tǒng)所設(shè)置的檢測機(jī)構(gòu)，及時(shí)地檢測出死鎖的發(fā)生，并精確地確定與死鎖有關(guān)的進(jìn)程和資源。檢測方法包括定時(shí)檢測、效率低時(shí)檢測、進(jìn)程等待時(shí)檢測等。

然后解除死鎖：采取適當(dāng)措施，從系統(tǒng)中將已發(fā)生的死鎖清除掉。

這是與檢測死鎖相配套的一種措施。當(dāng)檢測到系統(tǒng)中已發(fā)生死鎖時(shí)，須將進(jìn)程從死鎖狀態(tài)中解脫出來。常用的實(shí)施方法是撤銷或掛起一些進(jìn)程，以便回收一些資源，再將這些資源分配給已處于阻塞狀態(tài)的進(jìn)程，使之轉(zhuǎn)為就緒狀態(tài)，以繼續(xù)運(yùn)行。死鎖的檢測和解除措施，有可能使系統(tǒng)獲得較好的資源利用率和吞吐量，但在實(shí)現(xiàn)上難度也最大。

參考資料：死鎖百度百科

詳解MySQL（InnoDB）如何處理死鎖

鎖是需要事務(wù)結(jié)束后才釋放的。

一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。

為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復(fù)讀、幻讀）

官方定義：

兩階段鎖協(xié)議是指所有事務(wù)必須分兩個(gè)階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進(jìn)行讀、寫操作之前，事務(wù)首先要獲得對該數(shù)據(jù)的封鎖；在釋放一個(gè)封鎖之后，事務(wù)不再申請和獲得任何其他封鎖。

對應(yīng)到 MySQL 上分為兩個(gè)階段：

但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。

MySQL有兩種死鎖處理方式：

死鎖檢測 （默認(rèn)開啟）

死鎖檢測的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。

回滾

檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。

收集死鎖信息：

減少死鎖：

死鎖解決：

mysql解決死鎖問題

官方定義如下：兩個(gè)事務(wù)都持有對方需要的鎖，并且在等待對方釋放，并且雙方都不會(huì)釋放自己的鎖。

這個(gè)就好比你有一個(gè)人質(zhì)，對方有一個(gè)人質(zhì)，你們倆去談判說換人。你讓對面放人，對面讓你放人。

看到這里，也許你會(huì)有這樣的疑問，事務(wù)和談判不一樣，為什么事務(wù)不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖？這就涉及到 MySQL 的并發(fā)控制了。

MySQL的并發(fā)控制有兩種方式，一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。那么為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請求過來之后如同串行執(zhí)行的一樣（ 可串行化調(diào)度 ）。具體的并發(fā)控制這里不再展開。咱們繼續(xù)深入討論兩階段鎖協(xié)議。

官方定義：

對應(yīng)到 MySQL 上分為兩個(gè)階段：

就是說呢，只有遵循兩段鎖協(xié)議，才能實(shí)現(xiàn) 可串行化調(diào)度 。

但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖，并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。

MySQL有兩種死鎖處理方式：

由于性能原因，一般都是使用死鎖檢測來進(jìn)行處理死鎖。

死鎖檢測的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。

檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。

MySQL如何處理死鎖

解決一次mysql死鎖問題

多線程開啟事務(wù)處理。每個(gè)事務(wù)有多個(gè)update操作和一個(gè)insert操作（都在同一張表）。

默認(rèn)隔離級別：Repeatable Read

只有hotel_id=2和hotel_id=11111的數(shù)據(jù)

邏輯刪除原有數(shù)據(jù)

插入新的數(shù)據(jù)

根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時(shí)候沒有數(shù)據(jù)被更新

報(bào)了非常多一樣的錯(cuò)

發(fā)現(xiàn)居然有死鎖。

根據(jù)常識考慮，我每個(gè)線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會(huì)產(chǎn)生死鎖？

帶著這個(gè)問題，打印mysql最近一次的死鎖信息

show engine innodb status

顯示如下

發(fā)現(xiàn)事務(wù)1在等待一個(gè)鎖

事務(wù)2也在等待一個(gè)鎖

而且事物2持有了事物1需要的鎖

關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識儲備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識。

通過搜索引擎，

鎖的持有兼容程度如下表

那么再回到死鎖日志，可以知道 :

事務(wù)1正在獲取插入意向鎖

事務(wù)2正在獲取插入意向鎖，持有排他gap鎖

再看我們上面的鎖兼容表格，可以知道， gap lock和insert intention lock是不兼容的

那么就可以推斷出： 事務(wù)1持有g(shù)ap lock，等待事務(wù)2的insert intention lock釋放；事務(wù)2持有g(shù)ap lock，等待事務(wù)1的insert intention lock釋放，從而導(dǎo)致死鎖。

那么新的問題就來了，事務(wù)1的intention lock 為什么會(huì)和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會(huì)被事務(wù)2給鎖住？

讓我回顧一下gap lock的定義：

間隙鎖，鎖定一個(gè)范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況

那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識儲備還不夠。那就開始調(diào)查。

調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個(gè) 普通索引 的時(shí)候，會(huì)加一個(gè)gap lock來防止幻讀， 此gap lock 會(huì)鎖住一個(gè)左開右閉的區(qū)間。 假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時(shí)候，這個(gè)時(shí)候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時(shí)，就會(huì)處于等待獲取鎖的狀態(tài)。

ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料

MySQL 加鎖處理分析

回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：

因?yàn)槠胀ㄋ饕?/p>

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql會(huì)獲取一個(gè)gap lock，范圍(2,11111]

這段sql會(huì)獲取一個(gè)insert intention lock （waiting）

再看事務(wù)2的執(zhí)行過程

因?yàn)槠胀ㄋ饕?/p>

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql也會(huì)獲取一個(gè)gap lock，范圍也是(2,11111]（根據(jù)前面的知識，gap lock之間會(huì)互相兼容，可以一起持有鎖的）

這段sql也會(huì)獲取一個(gè)insert intention lock （waiting）

看到這里，基本也就破案了。因?yàn)槠胀ㄋ饕年P(guān)系，事務(wù)1和事務(wù)2的gap lock的覆蓋范圍太廣，導(dǎo)致其他事務(wù)無法插入數(shù)據(jù)。

重新梳理一下：

所以從結(jié)果來看，一堆事務(wù)被回滾，只有10007數(shù)據(jù)被更新成功

gap lock 導(dǎo)致了并發(fā)處理的死鎖

在mysql默認(rèn)的事務(wù)隔離級別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理。或者從業(yè)務(wù)層面做處理。

共享鎖、排他鎖、意向共享、意向排他

record lock、gap lock、next key lock、insert intention lock

show engine innodb status

標(biāo)題名稱：怎么避免死鎖mysql 避免死鎖的關(guān)鍵是什么?
文章鏈接：http://vcdvsql.cn/article34/dopegpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、響應(yīng)式網(wǎng)站、微信公眾號、網(wǎng)站設(shè)計(jì)公司、商城網(wǎng)站、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)