java線程中如何避免死鎖,java多線程避免死鎖

本文目錄一覽：

• 1、如何避免Java線程死鎖
• 2、如何避免Java多線程中的死鎖
• 3、北大青鳥java培訓：如何避免死鎖？

如何避免Java線程死鎖

Java線程死鎖需要如何解決，這個問題一直在我們不斷的使用中需要只有不斷的關鍵。不幸的是，使用上鎖會帶來其他問題。讓我們來看一些常見問題以及相應的解決方法： Java線程死鎖 Java線程死鎖是一個經典的多線程問題，因為不同的線程都在等待那些根本不可能被釋放的鎖，從而導致所有的工作都無法完成。假設有兩個線程，分別代表兩個飢餓的人，他們必須共享刀叉並輪流吃飯。他們都需要獲得兩個鎖：共享刀和共享叉的鎖。 假如線程 “A”獲得了刀，而線程“B”獲得了叉。線程“A”就會進入阻塞狀態來等待獲得叉，而線程“B”則阻塞來等待“A”所擁有的刀。這只是人為設計的例子，但儘管在運行時很難探測到，這類情況卻時常發生。雖然要探測或推敲各種情況是非常困難的，但只要按照下面幾條規則去設計系統，就能夠避免Java線程死鎖問題： 讓所有的線程按照同樣的順序獲得一組鎖。這種方法消除了 X 和 Y 的擁有者分別等待對方的資源的問題。 將多個鎖組成一組並放到同一個鎖下。前面Java線程死鎖的例子中，可以創建一個銀器對象的鎖。於是在獲得刀或叉之前都必須獲得這個銀器的鎖。 將那些不會阻塞的可獲得資源用變量標誌出來。當某個線程獲得銀器對象的鎖時，就可以通過檢查變量來判斷是否整個銀器集合中的對象鎖都可獲得。如果是，它就可以獲得相關的鎖，否則，就要釋放掉銀器這個鎖並稍後再嘗試。 最重要的是，在編寫代碼前認真仔細地設計整個系統。多線程是困難的，在開始編程之前詳細設計系統能夠幫助你避免難以發現Java線程死鎖的問題。 Volatile 變量，volatile 關鍵字是 Java 語言為優化編譯器設計的。以下面的代碼為例： 1.class VolatileTest {

2.public void foo() {

3.boolean flag = false;

4.if(flag) {

5.//this could happen

6.}

7.}

8.} 一個優化的編譯器可能會判斷出if部分的語句永遠不會被執行，就根本不會編譯這部分的代碼。如果這個類被多線程訪問， flag被前面某個線程設置之後，在它被if語句測試之前，可以被其他線程重新設置。用volatile關鍵字來聲明變量，就可以告訴編譯器在編譯的時候，不需要通過預測變量值來優化這部分的代碼。 無法訪問的Java線程死鎖有時候雖然獲取對象鎖沒有問題，線程依然有可能進入阻塞狀態。在 Java 編程中IO就是這類問題最好的例子。當線程因為對象內的IO調用而阻塞時，此對象應當仍能被其他線程訪問。該對象通常有責任取消這個阻塞的IO操作。造成阻塞調用的線程常常會令同步任務失敗。如果該對象的其他方法也是同步的，當線程被阻塞時，此對象也就相當於被冷凍住了。 其他的線程由於不能獲得對象的Java線程死鎖，就不能給此對象發消息(例如，取消 IO 操作)。必須確保不在同步代碼中包含那些阻塞調用，或確認在一個用同步阻塞代碼的對象中存在非同步方法。儘管這種方法需要花費一些注意力來保證結果代碼安全運行，但它允許在擁有對象的線程發生阻塞後，該對象仍能夠響應其他線程。 編輯推薦： 1. Java多線程優化之偏向鎖原理分析 2. Java多線程實現異步調用的方法 3. 使用Java多線程機制實現下載的方法介紹

如何避免Java多線程中的死鎖

死鎖產生的必要條件

產生死鎖必須同時滿足以下四個條件，只要其中任一條件不成立，死鎖就不會發生。

互斥條件：進程要求對所分配的資源（如打印機）進行排他性控制，即在一段時間內某 資源僅為一個進程所佔有。此時若有其他進程請求該資源，則請求進程只能等待。

不剝奪條件：進程所獲得的資源在未使用完畢之前，不能被其他進程強行奪走，即只能 由獲得該資源的進程自己來釋放（只能是主動釋放)。

請求和保持條件：進程已經保持了至少一個資源，但又提出了新的資源請求，而該資源 已被其他進程佔有，此時請求進程被阻塞，但對自己已獲得的資源保持不放。

循環等待條件：存在一種進程資源的循環等待鏈，鏈中每一個進程已獲得的資源同時被 鏈中下一個進程所請求。即存在一個處於等待狀態的進程集合{Pl, P2, …, pn}，其中Pi等 待的資源被P(i+1)佔有（i=0, 1, …, n-1)，Pn等待的資源被P0佔有

北大青鳥java培訓：如何避免死鎖？

什麼是死鎖，如何避免死鎖？線程A需要資源X，而線程B需要資源Y，而雙方都掌握有對方所要的資源，這種情況稱為死鎖（deadlock），或死亡擁抱（thedeadlyembrace）。

在並發程序設計中，江西電腦培訓建議死鎖(deadlock)是一種十分常見的邏輯錯誤。

通過採用正確的編程方式，死鎖的發生不難避免。

死鎖的四個必要條件在計算機專業的教材中，通常都會介紹死鎖的四個必要條件。

這四個條件缺一不可，或者說只要破壞了其中任何一個條件，死鎖就不可能發生。

我們來複習一下，這四個條件是：互斥（Mutualexclusion）：存在這樣一種資源，它在某個時刻只能被分配給一個執行緒（也稱為線程）使用；持有（Holdandwait）：當請求的資源已被佔用從而導致執行緒阻塞時，資源佔用者不但無需釋放該資源，而且還可以繼續請求更多資源；不可剝奪（Nopreemption）：執行緒獲得到的互斥資源不可被強行剝奪，換句話說，只有資源佔用者自己才能釋放資源；環形等待（Circularwait）：若干執行緒以不同的次序獲取互斥資源，從而形成環形等待的局面，想象在由多個執行緒組成的環形鏈中，每個執行緒都在等待下一個執行緒釋放它持有的資源。

解除死鎖的必要條件不難看出，在死鎖的四個必要條件中，第二、三和四項條件比較容易消除。

通過引入事務機制，往往可以消除第二、三兩項條件，方法是將所有上鎖操作均作為事務對待，一旦開始上鎖，即確保全部操作均可回退，同時通過鎖管理器檢測死鎖，並剝奪資源（回退事務）。

這種做法有時會造成較大開銷，而且也需要對上鎖模式進行較多改動。

消除第四項條件是比較容易且代價較低的辦法。

具體來說這種方法約定：上鎖的順序必須一致。

具體來說，我們人為地給鎖指定一種類似“水位”的方向性屬性。

無論已持有任何鎖，該執行緒所有的上鎖操作，必須按照一致的先後順序從低到高（或從高到低）進行，且在一個系統中，只允許使用一種先後次序。

請注意，放鎖的順序並不會導致死鎖。

也就是說，儘管按照鎖A,鎖B,放A,放B這樣的順序來進行鎖操作看上去有些怪異，但是只要大家都按先A後B的順序上鎖，便不會導致死鎖。

解決方法：1使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務（細化處理邏輯，執行一段邏輯後便回滾或者提交，然後再執行其它邏輯，直到事物執行完畢提交）；2設置死鎖超時參數為合理範圍，如：3分鐘-10分種；超過時間，自動放棄本次操作，避免進程懸掛； 3優化程序，檢查並避免死鎖現象出現； 4對所有的腳本和SP都要仔細測試，在正是版本之前。

 5所有的SP都要有錯誤處理（通過@error） 6一般不要修改SQLSERVER事務的默認級別。

不推薦強行加鎖另外參考的解決方法：按同一順序訪問對象如果所有並發事務按同一順序訪問對象，則發生死鎖的可能性會降低。

例如，如果兩個並發事務獲得Supplier表上的鎖，然後獲得Part表上的鎖，則在其中一個事務完成之前，另一個事務被阻塞在Supplier表上。

第一個事務提交或回滾後，第二個事務繼續進行。

不發生死鎖。

將存儲過程用於所有的數據修改可以標準化訪問對象的順序。