死鎖的前提是。兩個人吃飯，都需要需要刀和叉但又只有一套， 其中一個人拿了叉，另一個拿了刀，就出現(xiàn)互相等待的情況。你的obj1和obj2就相當于刀叉，但是你并沒有說拿了叉，還會繼續(xù)去拿刀。你的代碼意思是，t1拿叉，然后放下叉，然后去拿刀。t2做的動作是拿刀，放下刀，再拿叉。他們之間的動作并不會導致矛盾。我給你改成下面這樣了，但是這樣也不一定會導致死鎖，因為你沒有做循環(huán)，只做一次操作，萬一t1跑的快，瞬間就做完所有操作了，也不會阻塞t2.
成都創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網(wǎng)站制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的昌江網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！
if(Thread.currentThread().getName().equals("t1")){
synchronized(obj2){
System.out.println("線程1鎖定obj2");
synchronized(obj1){
System.out.println("線程1鎖定obj1");
}
}
}else if(Thread.currentThread().getName().equals("t2")){
synchronized(obj1){
System.out.println("線程2鎖定obj1");
synchronized(obj2){
System.out.println("線程2鎖定obj2");
}
}
}
主線程保持著A對象的鎖意思就是主線程正在處理A對象，其他線程不能處理，要等待主線程結束之后其他線程才能處理A對象。
同理副線程正在處理B對象，A不能處理，所以主線程結束不了，一直在等待。
兩個線程都運行不下去了就叫做死鎖，程序崩潰。
加鎖的意思就是某線程正在處理某對象，其他線程不能處理。
手打不容易，明白不明白都給分吧- -、
synchronized(obj){ ... } 稱之為對obj加鎖的同步代碼塊。 你可以這么理解，每一個java對象，都具有一個鎖標記。而這個鎖標記，同時只能分配給一個線程。 有synchronized(o)，意思是只有獲得o對象的鎖標記之后，后面的代碼塊才會執(zhí)行，否則會等待。 回到你的例子。x1和x2是兩個不同的Xianc對象，但是，對于static的屬性來說，任何Xianc對象都共享相同的值。因此，實際上，x1的o1屬性和x2的o1屬性指向同一個對象，而x1的o2屬性和x2的o2屬性也指向相同的對象。 也就是說，Xianc.o1和Xianc.o2表示兩個對象，這兩個對象被x1和x2作為靜態(tài)屬性共享。 然后，我們開始考慮鎖標記的事情。程序中創(chuàng)建了兩個線程t1和t2，并首先啟動了t1線程。t1線程與x1綁定，此時執(zhí)行的是flag == 0的代碼塊。 首先，遇到sync(o2)，由于此時o2的鎖標記還沒有被分配，因此t1線程就能獲得o2的鎖標記，進入代碼塊。 進入代碼塊之后，接下來是sleep。由于t1線程sleep之后，釋放了cpu，導致t2線程開始運行。由于t2線程與x2綁定，此時執(zhí)行的是flag == 1的代碼塊。 這時，t2線程遇到sync(o1)。由于o1的鎖標記沒有被分配，因此t2線程就能獲得o1的鎖標記，進入代碼塊。同樣的，進入代碼塊之后，t2也進入了sleep狀態(tài)，釋放了CPU。 過了一段時間，t1率先蘇醒，并被執(zhí)行。但是執(zhí)行過程中，會遇到syn(o1)。此時，o1的鎖標記被t2線程占據(jù)，t1無法獲得鎖標記，于是t1只能等待。 在等待過程中，t2也蘇醒了。但是t2遇到了syn(o2)，而此時o2的鎖標記被t1占據(jù)，因此t2也只能等待。 于是，兩個線程相互等待，就形成了死鎖。 手打，樓主給分
死鎖
死鎖是這樣一種情形：多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由于線程被無限期地阻塞，因此程序不可能正常終止。
導致死鎖的根源在于不適當?shù)剡\用“synchronized”關鍵詞來管理線程對特定對象的訪問。“synchronized”關鍵詞的作用是，確保在某個時刻只有一個線程被允許執(zhí)行特定的代碼塊，因此，被允許執(zhí)行的線程首先必須擁有對變量或對象的排他性的訪問權。當線程訪問對象時，線程會給對象加鎖，而這個鎖導致其它也想訪問同一對象的線程被阻塞，直至第一個線程釋放它加在對象上的鎖。
由于這個原因，在使用“synchronized”關鍵詞時，很容易出現(xiàn)兩個線程互相等待對方做出某個動作的情形。代碼一是一個導致死鎖的簡單例子。
//代碼一
class Deadlocker {
int field_1;
private Object lock_1 = new int[1];
int field_2;
private Object lock_2 = new int[1];
public void method1(int value) {
“synchronized” (lock_1) {
“synchronized” (lock_2) {
field_1 = 0; field_2 = 0;
}
}
}
public void method2(int value) {
“synchronized” (lock_2) {
“synchronized” (lock_1) {
field_1 = 0; field_2 = 0;
}
}
}
}
參考代碼一，考慮下面的過程：
◆ 一個線程（ThreadA）調用method1()。
◆ ThreadA在lock_1上同步，但允許被搶先執(zhí)行。
◆ 另一個線程（ThreadB）開始執(zhí)行。
◆ ThreadB調用method2()。
◆ ThreadB獲得lock_2，繼續(xù)執(zhí)行，企圖獲得lock_1。但ThreadB不能獲得lock_1，因為ThreadA占有l(wèi)ock_1。
◆ 現(xiàn)在，ThreadB阻塞，因為它在等待ThreadA釋放lock_1。
◆ 現(xiàn)在輪到ThreadA繼續(xù)執(zhí)行。ThreadA試圖獲得lock_2，但不能成功，因為lock_2已經(jīng)被ThreadB占有了。
◆ ThreadA和ThreadB都被阻塞，程序死鎖。
當然，大多數(shù)的死鎖不會這么顯而易見，需要仔細分析代碼才能看出，對于規(guī)模較大的多線程程序來說尤其如此。好的線程分析工具，例如JProbe Threadalyzer能夠分析死鎖并指出產生問題的代碼位置。
隱性死鎖
隱性死鎖由于不規(guī)范的編程方式引起，但不一定每次測試運行時都會出現(xiàn)程序死鎖的情形。由于這個原因，一些隱性死鎖可能要到應用正式發(fā)布之后才會被發(fā)現(xiàn)，因此它的危害性比普通死鎖更大。下面介紹兩種導致隱性死鎖的情況：加鎖次序和占有并等待。
加鎖次序
當多個并發(fā)的線程分別試圖同時占有兩個鎖時，會出現(xiàn)加鎖次序沖突的情形。如果一個線程占有了另一個線程必需的鎖，就有可能出現(xiàn)死鎖。考慮下面的情形，ThreadA和ThreadB兩個線程分別需要同時擁有l(wèi)ock_1、lock_2兩個鎖，加鎖過程可能如下：
◆ ThreadA獲得lock_1；
◆ ThreadA被搶占，VM調度程序轉到ThreadB；
◆ ThreadB獲得lock_2；
◆ ThreadB被搶占，VM調度程序轉到ThreadA；
◆ ThreadA試圖獲得lock_2，但lock_2被ThreadB占有，所以ThreadA阻塞；
◆ 調度程序轉到ThreadB；
◆ ThreadB試圖獲得lock_1，但lock_1被ThreadA占有，所以ThreadB阻塞；
◆ ThreadA和ThreadB死鎖。
必須指出的是，在代碼絲毫不做變動的情況下，有些時候上述死鎖過程不會出現(xiàn)，VM調度程序可能讓其中一個線程同時獲得lock_1和lock_2兩個鎖，即線程獲取兩個鎖的過程沒有被中斷。在這種情形下，常規(guī)的死鎖檢測很難確定錯誤所在。
占有并等待
如果一個線程獲得了一個鎖之后還要等待來自另一個線程的通知，可能出現(xiàn)另一種隱性死鎖，考慮代碼二。
//代碼二
public class queue {
static java.lang.Object queueLock_;
Producer producer_;
Consumer consumer_;
public class Producer {
void produce() {
while (!done) {
“synchronized” (queueLock_) {
produceItemAndAddItToQueue();
“synchronized” (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
“synchronized” (queueLock_) {
“synchronized” (consumer_) {
consumer_.wait();
}
removeItemFromQueueAndProcessIt();
}
}
}
}
}
}
在代碼二中，Producer向隊列加入一項新的內容后通知Consumer，以便它處理新的內容。問題在于，Consumer可能保持加在隊列上的鎖，阻止Producer訪問隊列，甚至在Consumer等待Producer的通知時也會繼續(xù)保持鎖。這樣，由于Producer不能向隊列添加新的內容，而Consumer卻在等待Producer加入新內容的通知，結果就導致了死鎖。
在等待時占有的鎖是一種隱性的死鎖，這是因為事情可能按照比較理想的情況發(fā)展—Producer線程不需要被Consumer占據(jù)的鎖。盡管如此，除非有絕對可靠的理由肯定Producer線程永遠不需要該鎖，否則這種編程方式仍是不安全的。有時“占有并等待”還可能引發(fā)一連串的線程等待，例如，線程A占有線程B需要的鎖并等待，而線程B又占有線程C需要的鎖并等待等。
要改正代碼二的錯誤，只需修改Consumer類，把wait()移出“synchronized”()即可。
Java線程死鎖需要如何解決，這個問題一直在我們不斷的使用中需要只有不斷的關鍵。不幸的是，使用上鎖會帶來其他問題。讓我們來看一些常見問題以及相應的解決方法： Java線程死鎖 Java線程死鎖是一個經(jīng)典的多線程問題，因為不同的線程都在等待那些根本不可能被釋放的鎖，從而導致所有的工作都無法完成。假設有兩個線程，分別代表兩個饑餓的人，他們必須共享刀叉并輪流吃飯。他們都需要獲得兩個鎖：共享刀和共享叉的鎖。 假如線程 “A”獲得了刀，而線程“B”獲得了叉。線程“A”就會進入阻塞狀態(tài)來等待獲得叉，而線程“B”則阻塞來等待“A”所擁有的刀。這只是人為設計的例子，但盡管在運行時很難探測到，這類情況卻時常發(fā)生。雖然要探測或推敲各種情況是非常困難的，但只要按照下面幾條規(guī)則去設計系統(tǒng)，就能夠避免Java線程死鎖問題： 讓所有的線程按照同樣的順序獲得一組鎖。這種方法消除了 X 和 Y 的擁有者分別等待對方的資源的問題。 將多個鎖組成一組并放到同一個鎖下。前面Java線程死鎖的例子中，可以創(chuàng)建一個銀器對象的鎖。于是在獲得刀或叉之前都必須獲得這個銀器的鎖。 將那些不會阻塞的可獲得資源用變量標志出來。當某個線程獲得銀器對象的鎖時，就可以通過檢查變量來判斷是否整個銀器集合中的對象鎖都可獲得。如果是，它就可以獲得相關的鎖，否則，就要釋放掉銀器這個鎖并稍后再嘗試。 最重要的是，在編寫代碼前認真仔細地設計整個系統(tǒng)。多線程是困難的，在開始編程之前詳細設計系統(tǒng)能夠幫助你避免難以發(fā)現(xiàn)Java線程死鎖的問題。 Volatile 變量，volatile 關鍵字是 Java 語言為優(yōu)化編譯器設計的。以下面的代碼為例： 1.class VolatileTest {
2.public void foo() {
3.boolean flag = false;
4.if(flag) {
5.//this could happen
6.}
7.}
8.} 一個優(yōu)化的編譯器可能會判斷出if部分的語句永遠不會被執(zhí)行，就根本不會編譯這部分的代碼。如果這個類被多線程訪問， flag被前面某個線程設置之后，在它被if語句測試之前，可以被其他線程重新設置。用volatile關鍵字來聲明變量，就可以告訴編譯器在編譯的時候，不需要通過預測變量值來優(yōu)化這部分的代碼。 無法訪問的Java線程死鎖有時候雖然獲取對象鎖沒有問題，線程依然有可能進入阻塞狀態(tài)。在 Java 編程中IO就是這類問題最好的例子。當線程因為對象內的IO調用而阻塞時，此對象應當仍能被其他線程訪問。該對象通常有責任取消這個阻塞的IO操作。造成阻塞調用的線程常常會令同步任務失敗。如果該對象的其他方法也是同步的，當線程被阻塞時，此對象也就相當于被冷凍住了。 其他的線程由于不能獲得對象的Java線程死鎖，就不能給此對象發(fā)消息(例如，取消 IO 操作)。必須確保不在同步代碼中包含那些阻塞調用，或確認在一個用同步阻塞代碼的對象中存在非同步方法。盡管這種方法需要花費一些注意力來保證結果代碼安全運行，但它允許在擁有對象的線程發(fā)生阻塞后，該對象仍能夠響應其他線程。 編輯推薦： 1. Java多線程優(yōu)化之偏向鎖原理分析 2. Java多線程實現(xiàn)異步調用的方法 3. 使用Java多線程機制實現(xiàn)下載的方法介紹
在基于Java Swing進行圖形界面開發(fā)的時候 經(jīng)常遇到的就是Swing多線程問題 我們可以想想一下 如果需要在一個圖形界面上顯示很多數(shù)據(jù) 這些數(shù)據(jù)是經(jīng)過長時間 復雜的查詢和運算得到的 如果在圖形界面的同一個線程中進行查詢和運算工作則會導致一段時間界面處于死機狀態(tài) 這會給用戶帶來不良的互動感受 為了解決這個問題 一般會單獨啟動一個線程進行運算和查詢工作 并隨時更新圖形界面 這時候 另一個問題就出現(xiàn)了 可能不僅沒有解決原來偶爾死機問題 還可能導致程序徹底死掉 幸運的是在JDK中暗藏了一個中斷程序的快捷鍵 就是CTRL+BREAK 這個快捷鍵Sun并沒有在文檔中公布 如果在命令行模式下啟動Java程序 然后按CTRL+BREAK鍵 會得到堆棧的跟蹤信息 從這些跟蹤信息中就可以知道具體引發(fā)死機的位置了
當一個程序產生死鎖的時候 你一定會希望盡快找到原因并且解決它 這時候 你一般的精力會用在查找引發(fā)死鎖的位置 另一半的精力會用于對堆棧進行跟蹤一確定引發(fā)死鎖的原因 但是在Java Swing程序中 你的所有努力可能都是沒有價值的 這是因為Java對Swing的多線程編程有一個特殊要求 就是在Swing里 只能在與Swing相同的線程里對GUI元件進行修改
也就是說 如果你要執(zhí)行類似于jLabel setText( blabla )代碼 必須在Swing線程中 而不允許在其他線程當中 如果必須在其他線程中修改元件 可以使用類似一下方式解決
SwingUtilities invokeLater(new Runnable() {
public void run() {
jLabel setText( blabla );
}
}
invokeLater方法雖然表面有時間延遲執(zhí)行含義 但是實際上幾乎沒有任何影響 可能在幾毫秒之內就會被執(zhí)行 另外還有一個invokeAndWait方法 除非特殊需要 否則幾乎是不用的
在不使用invokeLater的情況下 導致刷新問題是可以理解的 但是導致死鎖就優(yōu)點令人匪夷所思了 幸運的是 不是任何時候都需要調用改方法 這是因為大多數(shù)情況下 我們都是在與Swing同一個線程里進行界面更新 例如監(jiān)聽按鈕點擊事件的ActionListener actionPerformed方法就是運行在與Swing相同的線程中的 但是如果在回調類中引用了另一個類 并且是不屬于AWT/Swing的 那么結果就很難確定了 所以說使用invokeLater應該是最安全的
需要注意的是 在invokeLater做的任何事情 都會導致Swing線程窗口繪制工作暫停下來 等候invokeLater工作結束 所以不要在invokeLater進行耗時操作 盡量只執(zhí)行那些界面繪制相關的工作 可以通過代碼重構 將那些與界面更新相關的代碼集中起來統(tǒng)一處理
lishixinzhi/Article/program/Java/gj/201311/27498
重慶分公司
重慶分公司
