建站
咨詢
售后
建站咨詢
新聞中心
什么是死鎖（Deadlock）
死鎖是指兩個或兩個以上的線程在執(zhí)行過程中，因爭奪資源而造成的一種互相等待的現(xiàn)象。若無外力作用，它們都將無法推進下去。
目前創(chuàng)新互聯(lián)已為上1000家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)頁空間、網(wǎng)站托管、服務器托管、企業(yè)網(wǎng)站設計、遂溪網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
產(chǎn)生死鎖的四個必要條件得爛熟于心：
- 互斥條件：進程要求對所分配的資源進行排他性控制，即在一段時間內(nèi)某資源僅為一個進程所占用。此時若有其他進程請求該資源，則請求進程只能等待。
- 不剝奪條件：進程所獲得的資源在未使用完畢之前，不能被其他進程強行奪走，即只能由獲得該資源的進程自己來釋放。
- 請求和保持條件：進程已經(jīng)保持了至少一個資源，但又提出了新的資源請求，而該資源已被其他進程占有，此時請求進程被阻塞，但對自己已獲得的資源保持不放。
- 循環(huán)等待條件：存在一種進程資源的循環(huán)等待鏈，連中每一個進程已獲得的資源同時被鏈中下一個進程所請求。
相應的，如果想在程序運行之前預防發(fā)生死鎖（也成為 “死鎖預防”），必須設法破壞產(chǎn)生死鎖的四個必要條件之一
- 破壞互斥條件：允許系統(tǒng)資源都能共享使用，則系統(tǒng)不會進行死鎖狀態(tài)。這種方案并不太可行，因為有些資源根本就不能同時訪問，比如打印機。
- 破壞不剝奪條件：當一個已經(jīng)保持了某些不可剝奪資源的進程，請求新的資源時得不到滿足，它必須釋放已經(jīng)保持的所有資源，待以后需要時再重新申請。這種方法常用于狀態(tài)易于保存和恢復的資源，如 CPU 的寄存器及內(nèi)存資源，一般不能用于打印機之類的資源。
- 破壞請求和保持條件：采用預先靜態(tài)分配方法，即進程在運行前一次申請完他所需要的全部資源，在他的資源未滿足前，不把它投入運行。一旦運行后，這些資源就一直歸它所有，也不再提出其他資源請求，這樣就可以保證系統(tǒng)不會發(fā)生死鎖。
- 破壞循環(huán)等待條件：采用順序資源分配法。首先給系統(tǒng)中的資源編號，規(guī)定每個進程，必須按編號遞增的順序請求資源，同類資源一次申請完。也就是說，只要進程提出申請分配資源，則該進程在以后的資源申請中，只能申請編號比之前大的資源。
光看羅列出來的幾點文字肯定還是不能完全理解，下面會結(jié)合實例來給大伙解釋。
用 Java 寫一個死鎖
這絕對是面試中 Java 手寫題的 TOP2！?。〕巳吮M皆知的手寫單例模式，手寫死鎖可能有些小伙伴會遺漏掉。
邏輯其實非常簡單，我們申請兩個資源，開兩個線程，每個線程持有其中的一個資源，并且互相請求對方的資源，就構(gòu)成了死鎖。
MySQL 死鎖
MySQL 經(jīng)典的死鎖案例
下面來看個 MySQL 經(jīng)典的死鎖案例：轉(zhuǎn)賬
A 賬戶給 B 賬戶轉(zhuǎn)賬 50 元的同時，B 賬戶也給 A 賬戶轉(zhuǎn)賬 30 元
正常情況下，如果只有一個操作，A 給 B 轉(zhuǎn)賬 50 元，可以在一個事務內(nèi)完成，先獲取 A 用戶的余額和 B 用戶的余額，因為之后需要修改這兩條數(shù)據(jù)，所以需要通過寫鎖（for UPDATE）鎖住他們，防止其他事務更改導致我們的更改丟失而引起臟數(shù)據(jù)
但如果 A 給 B 轉(zhuǎn)賬和 B 給 A 轉(zhuǎn)賬同時發(fā)生，那就是兩個事務，可能發(fā)生死鎖：
1）A 用戶給 B 用戶轉(zhuǎn)賬 50 元，需在程序中開啟事務 1 來執(zhí)行 SQL，獲取 A 的余額同時鎖住 A 這條數(shù)據(jù)。
2）B 用戶給 A 用戶轉(zhuǎn)賬 30 元，需在程序中開啟事務 2 來執(zhí)行 SQL，并獲取 B 的余額同時鎖住 B 這條數(shù)據(jù)。
3）在事務 1 中執(zhí)行剩下的 SQL，此時事務 1 是獲取不到 B 的鎖的，也即 select for update 就會被阻塞??；
4）同理，事務 2 繼續(xù)執(zhí)行剩下的 SQL，請求 A 的鎖，也是獲取不到的
事務 1 和事務 2 存在相互等待獲取鎖的過程，導致兩個事務都掛起阻塞，最終拋出獲取鎖超時的異常。
如何解決 MySQL 死鎖
要想解決上述死鎖問題，我們可以從死鎖的四個必要條件入手。
指導思想其實很明確：就是保證 A 向 B 轉(zhuǎn)賬和 B 向 A 轉(zhuǎn)賬這兩個事務同一時刻只能有一個事務能成功獲取到鎖
由于互斥和不剝奪是鎖本質(zhì)的功能體現(xiàn)，無法修改，所以咱們從另外兩個條件嘗試去解決。
1）破壞 “請求和保持” 條件：A 和 B 之間的操作用同一個鎖鎖?。ū热缬?Redis 分布式鎖做，A 和 B 之間的鎖的 key 表示為 A:B，可以讓 id 小的用戶排在前面，id 大的用戶排在后面，這樣來設計 key。如果存在分庫分表的情況，用 hashcode 來做比較也行），保證 A 向 B 轉(zhuǎn)賬和 B 向 A 轉(zhuǎn)賬這兩個事務同一時刻只能有一個事務能成功獲取鎖
2）破壞 “循環(huán)等待” 條件：先獲取更小的鎖，獲取到了小的鎖才能獲取大鎖（所謂小鎖還是大鎖，也可以簡單的根據(jù)用戶的 id 來進行區(qū)分，先請求用戶 id 較小的，再請求用戶 id 較大的）。比如 A.id < B.id，那么 A 和 B 之間的操作，都是要先獲取 A 鎖，再獲取 B 鎖
具體代碼可參考如下：
? ?
分享標題：關(guān)于死鎖，面試的一切都在這里了
文章位置：http://www.5511xx.com/article/djscjpe.html
