加鎖情況與死鎖原因分析
創(chuàng)新互聯(lián)專注于做網(wǎng)站、成都網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站制作、網(wǎng)站開發(fā)。公司秉持“客戶至上,用心服務(wù)”的宗旨,從客戶的利益和觀點(diǎn)出發(fā),讓客戶在網(wǎng)絡(luò)營(yíng)銷中找到自己的駐足之地。尊重和關(guān)懷每一位客戶，用嚴(yán)謹(jǐn)?shù)膽B(tài)度對(duì)待客戶，用專業(yè)的服務(wù)創(chuàng)造價(jià)值，成為客戶值得信賴的朋友，為客戶解除后顧之憂。
為方便大家復(fù)現(xiàn)，完整表結(jié)構(gòu)和數(shù)據(jù)如下：
CREATE TABLE `t3` (
`c1` int(11) NOT NULL AUTO_INCREMENT,
`c2` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`),
UNIQUE KEY `c2` (`c2`)
) ENGINE=InnoDB
insert into t3 values(1,1),(15,15),(20,20);
在 session1 執(zhí)行 commit 的瞬間，我們會(huì)看到 session2、session3 的其中一個(gè)報(bào)死鎖。這個(gè)死鎖是這樣產(chǎn)生的：
1.?session1 執(zhí)行 delete ?會(huì)在唯一索引 c2 的 c2 = 15 這一記錄上加 X lock（也就是在MySQL 內(nèi)部觀測(cè)到的：X Lock but not gap）；
2.?session2 和 session3 在執(zhí)行 insert 的時(shí)候，由于唯一約束檢測(cè)發(fā)生唯一沖突，會(huì)加 S Next-Key Lock，即對(duì) (1,15] 這個(gè)區(qū)間加鎖包括間隙，并且被 seesion1 的 X Lock 阻塞，進(jìn)入等待；
3.?session1 在執(zhí)行 commit 后，會(huì)釋放 X Lock，session2 和 session3 都獲得 S Next-Key Lock；
4.?session2 和 session3 繼續(xù)執(zhí)行插入操作，這個(gè)時(shí)候 INSERT INTENTION LOCK（插入意向鎖）出現(xiàn)了，并且由于插入意向鎖會(huì)被 gap 鎖阻塞，所以 session2 和 session3 互相等待，造成死鎖。
死鎖日志如下：
請(qǐng)點(diǎn)擊輸入圖片描述
INSERT INTENTION LOCK
在之前的死鎖分析第四點(diǎn)，如果不分析插入意向鎖，也是會(huì)造成死鎖的，因?yàn)椴迦胱罱K還是要對(duì)記錄加 X Lock 的，session2 和 session3 還是會(huì)互相阻塞互相等待。
但是插入意向鎖是客觀存在的，我們可以在官方手冊(cè)中查到，不可忽略：
Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.
插入意向鎖其實(shí)是一種特殊的 gap lock，但是它不會(huì)阻塞其他鎖。假設(shè)存在值為 4 和 7 的索引記錄，嘗試插入值 5 和 6 的兩個(gè)事務(wù)在獲取插入行上的排它鎖之前使用插入意向鎖鎖定間隙，即在（4，7）上加 gap lock，但是這兩個(gè)事務(wù)不會(huì)互相沖突等待。
當(dāng)插入一條記錄時(shí)，會(huì)去檢查當(dāng)前插入位置的下一條記錄上是否存在鎖對(duì)象，如果下一條記錄上存在鎖對(duì)象，就需要判斷該鎖對(duì)象是否鎖住了 gap。如果 gap 被鎖住了，則插入意向鎖與之沖突，進(jìn)入等待狀態(tài)（插入意向鎖之間并不互斥）?？偨Y(jié)一下這把鎖的屬性：
1. 它不會(huì)阻塞其他任何鎖；
2. 它本身僅會(huì)被 gap lock 阻塞。
在學(xué)習(xí) MySQL 過程中，一般只有在它被阻塞的時(shí)候才能觀察到，所以這也是它常常被忽略的原因吧...
GAP LOCK
在此例中，另外一個(gè)重要的點(diǎn)就是 gap lock，通常情況下我們說到 gap lock 都只會(huì)聯(lián)想到 REPEATABLE-READ 隔離級(jí)別利用其解決幻讀。但實(shí)際上在 READ-COMMITTED 隔離級(jí)別，也會(huì)存在 gap lock ，只發(fā)生在：唯一約束檢查到有唯一沖突的時(shí)候，會(huì)加 S Next-key Lock，即對(duì)記錄以及與和上一條記錄之間的間隙加共享鎖。
通過下面這個(gè)例子就能驗(yàn)證：
請(qǐng)點(diǎn)擊輸入圖片描述
這里 session1 插入數(shù)據(jù)遇到唯一沖突，雖然報(bào)錯(cuò)，但是對(duì) (15,20] 加的 S Next-Key Lock 并不會(huì)馬上釋放，所以 session2 被阻塞。另外一種情況就是本文開始的例子，當(dāng) session2 插入遇到唯一沖突但是因?yàn)楸?X Lock 阻塞，并不會(huì)立刻報(bào)錯(cuò) “Duplicate key”，但是依然要等待獲取 S Next-Key Lock 。
有個(gè)困惑很久的疑問：出現(xiàn)唯一沖突需要加 S Next-Key Lock 是事實(shí)，但是加鎖的意義是什么？還是說是通過 S Next-Key Lock 來實(shí)現(xiàn)的唯一約束檢查，但是這樣意味著在插入沒有遇到唯一沖突的時(shí)候，這個(gè)鎖會(huì)立刻釋放，這不符合二階段鎖原則。這點(diǎn)希望能與大家一起討論得到好的解釋。
如果是在 REPEATABLE-READ，除以上所說的唯一約束沖突外，gap lock 的存在是這樣的：
普通索引（非唯一索引）的S/X Lock，都帶 gap 屬性，會(huì)鎖住記錄以及前1條記錄到后1條記錄的左閉右開區(qū)間，比如有[4,6,8]記錄，delete 6，則會(huì)鎖住[4,8）整個(gè)區(qū)間。
對(duì)于 gap lock，相信 DBA 們的心情是一樣一樣的，所以我的建議是：
1. 在絕大部分的業(yè)務(wù)場(chǎng)景下，都可以把 MySQL 的隔離界別設(shè)置為 READ-COMMITTED；
2. 在業(yè)務(wù)方便控制字段值唯一的情況下，盡量減少表中唯一索引的數(shù)量。
鎖沖突矩陣
前面我們說的 GAP LOCK 其實(shí)是鎖的屬性，另外我們知道 InnoDB 常規(guī)鎖模式有：S 和 X，即共享鎖和排他鎖。鎖模式和鎖屬性是可以隨意組合的，組合之后的沖突矩陣如下，這對(duì)我們分析死鎖很有幫助：
請(qǐng)點(diǎn)擊輸入圖片描述
以前參加過一個(gè)庫(kù)存系統(tǒng)，由于其業(yè)務(wù)復(fù)雜性，搞了很多個(gè)應(yīng)用來支撐。這樣的話一份庫(kù)存數(shù)據(jù)就有可能同時(shí)有多個(gè)應(yīng)用來修改庫(kù)存數(shù)據(jù)。
比如說，有定時(shí)任務(wù)域xx.cron，和SystemA域和SystemB域這幾個(gè)JAVA應(yīng)用，可能同時(shí)修改同一份庫(kù)存數(shù)據(jù)。如果不做協(xié)調(diào)的話，就會(huì)有臟數(shù)據(jù)出現(xiàn)。
對(duì)于跨JAVA進(jìn)程的線程協(xié)調(diào)，可以借助外部環(huán)境，例如DB或者Redis。下文介紹一下如何使用DB來實(shí)現(xiàn)分布式鎖。
本文設(shè)計(jì)的分布式鎖的交互方式如下：
在使用synchronized關(guān)鍵字的時(shí)候，必須指定一個(gè)鎖對(duì)象。
進(jìn)程內(nèi)的線程可以基于obj來實(shí)現(xiàn)同步。obj在這里可以理解為一個(gè)鎖對(duì)象。如果線程要進(jìn)入synchronized代碼塊里，必須先持有obj對(duì)象上的鎖。這種鎖是JAVA里面的內(nèi)置鎖，創(chuàng)建的過程是線程安全的。那么借助DB，如何保證創(chuàng)建鎖的過程是線程安全的呢？
可以利用DB中的UNIQUE KEY特性，一旦出現(xiàn)了重復(fù)的key，由于UNIQUE KEY的唯一性，會(huì)拋出異常的。在JAVA里面，是 SQLIntegrityConstraintViolationException 異常。
transaction_id是事務(wù)Id，比如說，可以用
來組裝一個(gè)transaction_id，表示某倉(cāng)庫(kù)某銷售模式下的某個(gè)條碼資源。不同條碼，當(dāng)然就有不同的transaction_id。如果有兩個(gè)應(yīng)用，拿著相同的transaction_id來創(chuàng)建鎖資源的時(shí)候，只能有一個(gè)應(yīng)用創(chuàng)建成功。
在寫操作頻繁的業(yè)務(wù)系統(tǒng)中，通常會(huì)進(jìn)行分庫(kù)，以降低單數(shù)據(jù)庫(kù)寫入的壓力，并提高寫操作的吞吐量。如果使用了分庫(kù)，那么業(yè)務(wù)數(shù)據(jù)自然也都分配到各個(gè)數(shù)據(jù)庫(kù)上了。
在這種水平切分的多數(shù)據(jù)庫(kù)上使用DB分布式鎖，可以自定義一個(gè)DataSouce列表。并暴露一個(gè) getConnection(String transactionId) 方法，按照transactionId找到對(duì)應(yīng)的Connection。
實(shí)現(xiàn)代碼如下：
首先編寫一個(gè)initDataSourceList方法，并利用Spring的PostConstruct注解初始化一個(gè)DataSource 列表。相關(guān)的DB配置從db.properties讀取。
DataSource使用阿里的DruidDataSource。
接著最重要的一個(gè)實(shí)現(xiàn)getConnection(String transactionId)方法。實(shí)現(xiàn)原理很簡(jiǎn)單，獲取transactionId的hashcode，并對(duì)DataSource的長(zhǎng)度取模即可。
連接池列表設(shè)計(jì)好后，就可以實(shí)現(xiàn)往distributed_lock表插入數(shù)據(jù)了。
接下來利用DB的 select for update 特性來鎖住線程。當(dāng)多個(gè)線程根據(jù)相同的transactionId并發(fā)同時(shí)操作 select for update 的時(shí)候，只有一個(gè)線程能成功，其他線程都block住，直到 select for update 成功的線程使用commit操作后，block住的所有線程的其中一個(gè)線程才能開始干活。
我們?cè)谏厦娴腄istributedLock類中創(chuàng)建一個(gè)lock方法。
當(dāng)線程執(zhí)行完任務(wù)后，必須手動(dòng)的執(zhí)行解鎖操作，之前被鎖住的線程才能繼續(xù)干活。在我們上面的實(shí)現(xiàn)中，其實(shí)就是獲取到當(dāng)時(shí) select for update 成功的線程對(duì)應(yīng)的Connection，并實(shí)行commit操作即可。
那么如何獲取到呢？我們可以利用ThreadLocal。首先在DistributedLock類中定義
每次調(diào)用lock方法的時(shí)候，把Connection放置到ThreadLocal里面。我們修改lock方法。
這樣子，當(dāng)獲取到Connection后，將其設(shè)置到ThreadLocal中，如果lock方法出現(xiàn)異常，則將其從ThreadLocal中移除掉。
有了這幾步后，我們可以來實(shí)現(xiàn)解鎖操作了。我們?cè)贒istributedLock添加一個(gè)unlock方法。
畢竟是利用DB來實(shí)現(xiàn)分布式鎖，對(duì)DB還是造成一定的壓力。當(dāng)時(shí)考慮使用DB做分布式的一個(gè)重要原因是，我們的應(yīng)用是后端應(yīng)用，平時(shí)流量不大的，反而關(guān)鍵的是要保證庫(kù)存數(shù)據(jù)的正確性。對(duì)于像前端庫(kù)存系統(tǒng)，比如添加購(gòu)物車占用庫(kù)存等操作，最好別使用DB來實(shí)現(xiàn)分布式鎖了。
如果想鎖住多份數(shù)據(jù)該怎么實(shí)現(xiàn)？比如說，某個(gè)庫(kù)存操作，既要修改物理庫(kù)存，又要修改虛擬庫(kù)存，想鎖住物理庫(kù)存的同時(shí)，又鎖住虛擬庫(kù)存。其實(shí)也不是很難，參考lock方法，寫一個(gè)multiLock方法，提供多個(gè)transactionId的入?yún)ⅲ琭or循環(huán)處理就可以了。這個(gè)后續(xù)有時(shí)間再補(bǔ)上。
重新啟動(dòng)MySQL：
[root@bogon ~]# /etc/rc.d/init.d/mysql restart
Shutting down MySQL [ 確定 ]
Starting MySQL. [ 確定 ]
[root@bogon ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.22-rc-community-log MySQL Community Edition (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql 為并發(fā)事務(wù)同時(shí)對(duì)一條記錄進(jìn)行讀寫時(shí)，提出了兩種解決方案：
1）使用 mvcc 的方法，實(shí)現(xiàn)多事務(wù)的并發(fā)讀寫，但是這種讀只是“快照讀”，一般讀的是歷史版本數(shù)據(jù)，還有一種是“當(dāng)前讀”，一般加鎖實(shí)現(xiàn)“當(dāng)前讀”，或者 insert、update、delete 也是當(dāng)前讀。
2）使用加鎖的方法，鎖分為共享鎖（讀鎖），排他鎖（寫鎖）
快照讀：就是select
當(dāng)前讀：特殊的讀操作，插入/更新/刪除操作，屬于當(dāng)前讀，處理的都是當(dāng)前的數(shù)據(jù)，需要加鎖。
mysql 在 RR 級(jí)別怎么處理幻讀的呢？一般來說，RR 級(jí)別通過 mvcc 機(jī)制，保證讀到低于后面事務(wù)的數(shù)據(jù)。但是 select for update 不會(huì)觸發(fā) mvcc，它是當(dāng)前讀。如果后面事務(wù)插入數(shù)據(jù)并提交，那么在 RR 級(jí)別就會(huì)讀到插入的數(shù)據(jù)。所以，mysql 使用 行鎖 + gap 鎖（簡(jiǎn)稱 next-key 鎖）來防止當(dāng)前讀的時(shí)候插入。
Gap Lock在InnoDB的唯一作用就是防止其他事務(wù)的插入操作，以此防止幻讀的發(fā)生。
Innodb自動(dòng)使用間隙鎖的條件：
重慶分公司
重慶分公司
