資訊專欄INFORMATION COLUMN
由于加鎖順序不一致造成的死鎖在RC(READ-COMMIT)隔離級別下較為常見，本文分享一個RR(REPEATABLE-READ)隔離級別下由于GAP鎖導(dǎo)致的死鎖案例。
得知有死鎖發(fā)生時，首先查看數(shù)據(jù)庫隔離級別為默認(rèn)的RR(REPEATABLE-READ)模式：
然后再查看innodb存儲引擎日志可以看到最近一次死鎖的相關(guān)信息：
從日志中我們可以看出死鎖發(fā)生在表T_ORDERBILL_TASK上而且是兩條相同類型的針對表T_ORDERBILL_TASK插入的insert語句！檢查T_ORDERBILL_TASK表結(jié)構(gòu)如下：
可見ORG_CODE上有二級索引。
(1) TRANSACTION也就是第一個事務(wù)的信息中：
l WAITING FOR THIS LOCK TO BE GRANTED，表示的是這個事務(wù)在等待的鎖信息；
l index ORG_CODE of table `T_BSE_QUERY_SCHEME`.`T_ORDERBILL_TASK`表示等的是表T_ORDERBILL_TASK上ORG_CODE索引上面的鎖；
l lock_mode X locks gap before rec insert intention waiting Record lock 表示這個語句要加一個插入意向鎖但是還在等待狀態(tài)，Record lock說明這是一個記錄鎖。
(2) TRANSACTION 也就是第二個事務(wù)中：
l (2) HOLDS THE LOCK(S)中l(wèi)ock_mode X locks gap before rec 表示了持有GAP鎖
l (2) WAITING FOR THIS LOCK TO BE GRANTED中l(wèi)ock_mode X locks gap before rec insert intention waiting同（1）TRANSACTION等待加插入意向鎖
結(jié)合業(yè)務(wù)開發(fā)提供的該模塊兒的業(yè)務(wù)邏輯和發(fā)生死鎖時間上下文業(yè)務(wù)日志可以整理出事務(wù)1和事務(wù)2的執(zhí)行順序為：
或者
可以看出在插入一條數(shù)據(jù)前先執(zhí)行當(dāng)前讀鎖住該條數(shù)據(jù)，若不存在則插入該條數(shù)據(jù)，否則執(zhí)行update。
由于索引是順序存儲的，查出110026介于110019和110036之間：
由此可知：
當(dāng)session 1執(zhí)行select ... for update當(dāng)前讀，由于ORG_CODE = 110026的數(shù)據(jù)不存在，因此會加上gap鎖(110019,110036)。
Session 2執(zhí)行select ... for update當(dāng)前讀,同樣也會加上gap鎖(110019,110036)，由于gap鎖不互斥，所以該語句也可成功執(zhí)行。
但是到第三步時無論是session 1先插入還是session 2先插入都會等待對方的gap鎖，第四步時后插入的也會被對方的gap鎖阻塞。兩個session進(jìn)入互相等待狀態(tài)形成死鎖，最后死鎖檢測將session2回滾。
其實(shí)GAP鎖，就是RR隔離級別相對于RC隔離級別不會出現(xiàn)幻讀的關(guān)鍵。在RR隔離級別下，條件列上為非唯一索引時，當(dāng)前讀通過條件列未定位到滿足條件的記錄時會加GAP鎖，保證后續(xù)的insert不能插入相同值的數(shù)據(jù)，以防止出現(xiàn)幻讀。需要注意的是GAP鎖并不互斥但是和插入意向鎖互斥。相同語句的情況下RR模式由于會加GAP鎖可能鎖住更多的數(shù)據(jù)，雖然防止了幻讀，但是會影響一定的并發(fā)。在配置RC和RR隔離級別的時候一定要根據(jù)業(yè)務(wù)場景進(jìn)行選擇。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/130127.html
摘要：問題描述近期項目需要從虛擬機(jī)環(huán)境遷移到容器環(huán)境，其中有一個項目在遷移到容器環(huán)境之后的兩天之內(nèi)出現(xiàn)了次死鎖的問題，部分關(guān)鍵日志如下日志還是挺明顯的，線程獲得了鎖，等待獲取而正好相反，從而導(dǎo)致死鎖問題分析以上的錯誤 問題描述 近期項目需要從虛擬機(jī)環(huán)境遷移到容器環(huán)境，其中有一個項目在遷移到容器環(huán)境之后的兩天之內(nèi)出現(xiàn)了2次死鎖(deadlock)的問題，部分關(guān)鍵日志如下： Found one ...
摘要：的情況下，必然就會死鎖，對吧，接下來怎么用驗證呢切到號線程查看線程棧及棧對象。死鎖原因分析死鎖原因分析要想追究死鎖的原因，只能仔細(xì)推敲線程棧線程棧對象。在幾個痙攣過程中進(jìn)入了另外一個線程池的方法中，希望能得到該池中的鎖對象。一：背景1. 講故事這個月初，星球里的一位朋友找到我，說他的程序出現(xiàn)了死鎖，懷疑是自己的某些寫法導(dǎo)致mongodb出現(xiàn)了如此尷尬的情況，截圖如下：說實(shí)話，看過這么多dum...
摘要：此時我想到了福爾摩斯說過的一句話當(dāng)你排除掉各種不可能出現(xiàn)的情況之后，剩下的情況無論多么難以置信，都是真相。福爾摩斯冷靜下來想一想，這個線程，有可能靜悄悄地退出了嗎，沒留下半點(diǎn)異常日志從理論上來說，不可能。配置建議最后，附上一份配置建議。 1、事發(fā) 我們有個視頻處理程序，基于 SpringBoot，會啟動幾個線程來跑。要退出程序時，會發(fā)送一個信號給程序，每個線程收到信號后會平滑退出，等全...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
