什么是線程死鎖？死鎖如何產(chǎn)生？如何避免線程死鎖？

死鎖的介紹：

線程死鎖是指由于兩個(gè)或者多個(gè)線程互相持有對(duì)方所需要的資源，導(dǎo)致這些線程處于等待狀態(tài)，無(wú)法前往執(zhí)行。當(dāng)線程進(jìn)入對(duì)象的synchronized代碼塊時(shí)，便占有了資源，直到它退出該代碼塊或者調(diào)用wait方法，才釋放資源，在此期間，其他線程將不能進(jìn)入該代碼塊。當(dāng)線程互相持有對(duì)方所需要的資源時(shí)，會(huì)互相等待對(duì)方釋放資源，如果線程都不主動(dòng)釋放所占有的資源，將產(chǎn)生死鎖。

死鎖的產(chǎn)生的一些特定條件：

1、互斥條件：進(jìn)程對(duì)于所分配到的資源具有排它性，即一個(gè)資源只能被一個(gè)進(jìn)程占用，直到被該進(jìn)程釋放 。

2、請(qǐng)求和保持條件：一個(gè)進(jìn)程因請(qǐng)求被占用資源而發(fā)生阻塞時(shí)，對(duì)已獲得的資源保持不放。 

3、不剝奪條件：任何一個(gè)資源在沒(méi)被該進(jìn)程釋放之前，任何其他進(jìn)程都無(wú)法對(duì)他剝奪占用。

4、循環(huán)等待條件：當(dāng)發(fā)生死鎖時(shí)，所等待的進(jìn)程必定會(huì)形成一個(gè)環(huán)路（類似于死循環(huán)），造成永久阻塞。

如何避免：

1、加鎖順序：

當(dāng)多個(gè)線程需要相同的一些鎖，但是按照不同的順序加鎖，死鎖就很容易發(fā)生。如果能確保所有的線程都是按照相同的順序獲得鎖，那么死鎖就不會(huì)發(fā)生。當(dāng)然這種方式需要你事先知道所有可能會(huì)用到的鎖，然而總有些時(shí)候是無(wú)法預(yù)知的。

2、加鎖時(shí)限：

加上一個(gè)超時(shí)時(shí)間，若一個(gè)線程沒(méi)有在給定的時(shí)限內(nèi)成功獲得所有需要的鎖，則會(huì)進(jìn)行回退并釋放所有已經(jīng)獲得的鎖，然后等待一段隨機(jī)的時(shí)間再重試。但是如果有非常多的線程同一時(shí)間去競(jìng)爭(zhēng)同一批資源，就算有超時(shí)和回退機(jī)制，還是可能會(huì)導(dǎo)致這些線程重復(fù)地嘗試但卻始終得不到鎖。

3、死鎖檢測(cè)：

死鎖檢測(cè)即每當(dāng)一個(gè)線程獲得了鎖，會(huì)在線程和鎖相關(guān)的數(shù)據(jù)結(jié)構(gòu)中（map、graph等等）將其記下。除此之外，每當(dāng)有線程請(qǐng)求鎖，也需要記錄在這個(gè)數(shù)據(jù)結(jié)構(gòu)中。死鎖檢測(cè)是一個(gè)更好的死鎖預(yù)防機(jī)制，它主要是針對(duì)那些不可能實(shí)現(xiàn)按序加鎖并且鎖超時(shí)也不可行的場(chǎng)景。

notify和notifyAll區(qū)別

他們的作用都是通知處于等待該對(duì)象的線程。

1、notifyAll使所有原來(lái)在該對(duì)象上等待被notify的線程統(tǒng)統(tǒng)退出wait的狀態(tài)，變成等待該對(duì)象上的鎖，一旦該對(duì)象被解鎖，他們就會(huì)去競(jìng)爭(zhēng)。

2、notify是通知其中一個(gè)線程，不會(huì)通知所有的線程。

談一談對(duì)MySQL InnoDB的認(rèn)識(shí)

介紹：

InnoDB引擎是MySQL數(shù)據(jù)庫(kù)的一個(gè)重要的存儲(chǔ)引擎,和其他存儲(chǔ)引擎相比,InnoDB引擎的優(yōu)點(diǎn)是支持兼容ACID的事務(wù)(類似于PostgreSQL),以及參數(shù)完整性(有外鍵)等?，F(xiàn)在Innobase實(shí)行雙認(rèn)證授權(quán).MySQL5.5.5以后默認(rèn)的存儲(chǔ)引擎都是InnoDB引擎。

特點(diǎn)是：

1、具有較好的事務(wù)支持：支持4個(gè)事務(wù)隔離級(jí)別，支持多版本讀

2、行級(jí)鎖定：通過(guò)索引實(shí)現(xiàn)，全表掃描仍然會(huì)是表鎖，注意間隙鎖的影響

3、讀寫阻塞與事務(wù)隔離級(jí)別相關(guān)

4、具有非常高效的緩存特性：能緩存索引，也能緩存數(shù)據(jù)

5、整個(gè)表和主鍵以Cluster方式存儲(chǔ)，組成一顆平衡樹

6、所有Secondary Index都會(huì)保存主鍵信息

適用場(chǎng)景：

1、需要事務(wù)支持（具有較好的事務(wù)特性）

2、行級(jí)鎖定對(duì)高并發(fā)有很好的適應(yīng)能力，但需要確保查詢是通過(guò)索引完成

3、數(shù)據(jù)更新較為頻繁的場(chǎng)景

4、數(shù)據(jù)一致性要求較高

5、硬件設(shè)備內(nèi)存較大，可以利用InnoDB較好的緩存能力來(lái)提高內(nèi)存利用率，盡可能減少磁盤IO

談一談數(shù)據(jù)庫(kù)事務(wù)的隔離級(jí)別？

1、Read uncommitted（讀未提交）就是一個(gè)事務(wù)可以讀取另一個(gè)未提交事務(wù)的數(shù)據(jù)。

2、Read committed（讀提交）就是一個(gè)事務(wù)要等另一個(gè)事務(wù)提交后才能讀取數(shù)據(jù)。

3、Repeatable read（重復(fù)讀）就是在開始讀取數(shù)據(jù)（事務(wù)開啟）時(shí)，不再允許修改操作。

4、Serializable（序列化）在該級(jí)別下，事務(wù)串行化順序執(zhí)行，可以避免臟讀、不可重復(fù)讀與幻讀。是最高的事務(wù)隔離級(jí)別，但是這種事務(wù)隔離級(jí)別效率低下，比較耗數(shù)據(jù)庫(kù)性能，一般不使用。