什么是死鎖（Deadlock）

死鎖是指兩個(gè)或兩個(gè)以上的線程在執(zhí)行過(guò)程中，因爭(zhēng)奪資源而造成的一種互相等待的現(xiàn)象。若無(wú)外力作用，它們都將無(wú)法推進(jìn)下去。

產(chǎn)生死鎖的四個(gè)必要條件得爛熟于心：

• 互斥條件：進(jìn)程要求對(duì)所分配的資源進(jìn)行排他性控制，即在一段時(shí)間內(nèi)某資源僅為一個(gè)進(jìn)程所占用。此時(shí)若有其他進(jìn)程請(qǐng)求該資源，則請(qǐng)求進(jìn)程只能等待。
• 不剝奪條件：進(jìn)程所獲得的資源在未使用完畢之前，不能被其他進(jìn)程強(qiáng)行奪走，即只能由獲得該資源的進(jìn)程自己來(lái)釋放。
• 請(qǐng)求和保持條件：進(jìn)程已經(jīng)保持了至少一個(gè)資源，但又提出了新的資源請(qǐng)求，而該資源已被其他進(jìn)程占有，此時(shí)請(qǐng)求進(jìn)程被阻塞，但對(duì)自己已獲得的資源保持不放。
• 循環(huán)等待條件：存在一種進(jìn)程資源的循環(huán)等待鏈，連中每一個(gè)進(jìn)程已獲得的資源同時(shí)被鏈中下一個(gè)進(jìn)程所請(qǐng)求。

相應(yīng)的，如果想在程序運(yùn)行之前預(yù)防發(fā)生死鎖（也成為 “死鎖預(yù)防”），必須設(shè)法破壞產(chǎn)生死鎖的四個(gè)必要條件之一

• 破壞互斥條件：允許系統(tǒng)資源都能共享使用，則系統(tǒng)不會(huì)進(jìn)行死鎖狀態(tài)。這種方案并不太可行，因?yàn)橛行┵Y源根本就不能同時(shí)訪問(wèn)，比如打印機(jī)。
• 破壞不剝奪條件：當(dāng)一個(gè)已經(jīng)保持了某些不可剝奪資源的進(jìn)程，請(qǐng)求新的資源時(shí)得不到滿足，它必須釋放已經(jīng)保持的所有資源，待以后需要時(shí)再重新申請(qǐng)。這種方法常用于狀態(tài)易于保存和恢復(fù)的資源，如 CPU 的寄存器及內(nèi)存資源，一般不能用于打印機(jī)之類(lèi)的資源。
• 破壞請(qǐng)求和保持條件：采用預(yù)先靜態(tài)分配方法，即進(jìn)程在運(yùn)行前一次申請(qǐng)完他所需要的全部資源，在他的資源未滿足前，不把它投入運(yùn)行。一旦運(yùn)行后，這些資源就一直歸它所有，也不再提出其他資源請(qǐng)求，這樣就可以保證系統(tǒng)不會(huì)發(fā)生死鎖。
• 破壞循環(huán)等待條件：采用順序資源分配法。首先給系統(tǒng)中的資源編號(hào)，規(guī)定每個(gè)進(jìn)程，必須按編號(hào)遞增的順序請(qǐng)求資源，同類(lèi)資源一次申請(qǐng)完。也就是說(shuō)，只要進(jìn)程提出申請(qǐng)分配資源，則該進(jìn)程在以后的資源申請(qǐng)中，只能申請(qǐng)編號(hào)比之前大的資源。

光看羅列出來(lái)的幾點(diǎn)文字肯定還是不能完全理解，下面會(huì)結(jié)合實(shí)例來(lái)給大伙解釋。

用 Java 寫(xiě)一個(gè)死鎖

這絕對(duì)是面試中 Java 手寫(xiě)題的 TOP2?。?！除了人盡皆知的手寫(xiě)單例模式，手寫(xiě)死鎖可能有些小伙伴會(huì)遺漏掉。

邏輯其實(shí)非常簡(jiǎn)單，我們申請(qǐng)兩個(gè)資源，開(kāi)兩個(gè)線程，每個(gè)線程持有其中的一個(gè)資源，并且互相請(qǐng)求對(duì)方的資源，就構(gòu)成了死鎖。

MySQL 死鎖

MySQL 經(jīng)典的死鎖案例

下面來(lái)看個(gè) MySQL 經(jīng)典的死鎖案例：轉(zhuǎn)賬

A 賬戶給 B 賬戶轉(zhuǎn)賬 50 元的同時(shí)，B 賬戶也給 A 賬戶轉(zhuǎn)賬 30 元

正常情況下，如果只有一個(gè)操作，A 給 B 轉(zhuǎn)賬 50 元，可以在一個(gè)事務(wù)內(nèi)完成，先獲取 A 用戶的余額和 B 用戶的余額，因?yàn)橹笮枰薷倪@兩條數(shù)據(jù)，所以需要通過(guò)寫(xiě)鎖（for UPDATE）鎖住他們，防止其他事務(wù)更改導(dǎo)致我們的更改丟失而引起臟數(shù)據(jù)

但如果 A 給 B 轉(zhuǎn)賬和 B 給 A 轉(zhuǎn)賬同時(shí)發(fā)生，那就是兩個(gè)事務(wù)，可能發(fā)生死鎖：

1）A 用戶給 B 用戶轉(zhuǎn)賬 50 元，需在程序中開(kāi)啟事務(wù) 1 來(lái)執(zhí)行 SQL，獲取 A 的余額同時(shí)鎖住 A 這條數(shù)據(jù)。

2）B 用戶給 A 用戶轉(zhuǎn)賬 30 元，需在程序中開(kāi)啟事務(wù) 2 來(lái)執(zhí)行 SQL，并獲取 B 的余額同時(shí)鎖住 B 這條數(shù)據(jù)。

3）在事務(wù) 1 中執(zhí)行剩下的 SQL，此時(shí)事務(wù) 1 是獲取不到 B 的鎖的，也即 select for update 就會(huì)被阻塞??；

4）同理，事務(wù) 2 繼續(xù)執(zhí)行剩下的 SQL，請(qǐng)求 A 的鎖，也是獲取不到的

事務(wù) 1 和事務(wù) 2 存在相互等待獲取鎖的過(guò)程，導(dǎo)致兩個(gè)事務(wù)都掛起阻塞，最終拋出獲取鎖超時(shí)的異常。

如何解決 MySQL 死鎖

要想解決上述死鎖問(wèn)題，我們可以從死鎖的四個(gè)必要條件入手。

指導(dǎo)思想其實(shí)很明確：就是保證 A 向 B 轉(zhuǎn)賬和 B 向 A 轉(zhuǎn)賬這兩個(gè)事務(wù)同一時(shí)刻只能有一個(gè)事務(wù)能成功獲取到鎖

由于互斥和不剝奪是鎖本質(zhì)的功能體現(xiàn)，無(wú)法修改，所以咱們從另外兩個(gè)條件嘗試去解決。

1）破壞 “請(qǐng)求和保持” 條件：A 和 B 之間的操作用同一個(gè)鎖鎖?。ū热缬?Redis 分布式鎖做，A 和 B 之間的鎖的 key 表示為 A:B，可以讓 id 小的用戶排在前面，id 大的用戶排在后面，這樣來(lái)設(shè)計(jì) key。如果存在分庫(kù)分表的情況，用 hashcode 來(lái)做比較也行），保證 A 向 B 轉(zhuǎn)賬和 B 向 A 轉(zhuǎn)賬這兩個(gè)事務(wù)同一時(shí)刻只能有一個(gè)事務(wù)能成功獲取鎖

2）破壞 “循環(huán)等待” 條件：先獲取更小的鎖，獲取到了小的鎖才能獲取大鎖（所謂小鎖還是大鎖，也可以簡(jiǎn)單的根據(jù)用戶的 id 來(lái)進(jìn)行區(qū)分，先請(qǐng)求用戶 id 較小的，再請(qǐng)求用戶 id 較大的）。比如 A.id < B.id，那么 A 和 B 之間的操作，都是要先獲取 A 鎖，再獲取 B 鎖

具體代碼可參考如下：

? ?