line = bufferedReader.readLine();//死鎖位置
站在用戶的角度思考問(wèn)題,與客戶深入溝通,找到高縣網(wǎng)站設(shè)計(jì)與高縣網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗(yàn),讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品,建站類型包括:成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、國(guó)際域名空間、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋高縣地區(qū)。
會(huì)等待,所以會(huì)。
用另一個(gè)線程讀、主線程檢測(cè)是否命令終止了。
死鎖
死鎖是這樣一種情形:多個(gè)線程同時(shí)被阻塞,它們中的一個(gè)或者全部都在等待某個(gè)資源被釋放。由于線程被無(wú)限期地阻塞,因此程序不可能正常終止。
導(dǎo)致死鎖的根源在于不適當(dāng)?shù)剡\(yùn)用“synchronized”關(guān)鍵詞來(lái)管理線程對(duì)特定對(duì)象的訪問(wèn)?!皊ynchronized”關(guān)鍵詞的作用是,確保在某個(gè)時(shí)刻只有一個(gè)線程被允許執(zhí)行特定的代碼塊,因此,被允許執(zhí)行的線程首先必須擁有對(duì)變量或?qū)ο蟮呐潘缘脑L問(wèn)權(quán)。當(dāng)線程訪問(wèn)對(duì)象時(shí),線程會(huì)給對(duì)象加鎖,而這個(gè)鎖導(dǎo)致其它也想訪問(wèn)同一對(duì)象的線程被阻塞,直至第一個(gè)線程釋放它加在對(duì)象上的鎖。
由于這個(gè)原因,在使用“synchronized”關(guān)鍵詞時(shí),很容易出現(xiàn)兩個(gè)線程互相等待對(duì)方做出某個(gè)動(dòng)作的情形。代碼一是一個(gè)導(dǎo)致死鎖的簡(jiǎ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;
}
}
}
}
參考代碼一,考慮下面的過(guò)程:
◆ 一個(gè)線程(ThreadA)調(diào)用method1()。
◆ ThreadA在lock_1上同步,但允許被搶先執(zhí)行。
◆ 另一個(gè)線程(ThreadB)開(kāi)始執(zhí)行。
◆ ThreadB調(diào)用method2()。
◆ ThreadB獲得lock_2,繼續(xù)執(zhí)行,企圖獲得lock_1。但ThreadB不能獲得lock_1,因?yàn)門hreadA占有l(wèi)ock_1。
◆ 現(xiàn)在,ThreadB阻塞,因?yàn)樗诘却齌hreadA釋放lock_1。
◆ 現(xiàn)在輪到ThreadA繼續(xù)執(zhí)行。ThreadA試圖獲得lock_2,但不能成功,因?yàn)閘ock_2已經(jīng)被ThreadB占有了。
◆ ThreadA和ThreadB都被阻塞,程序死鎖。
當(dāng)然,大多數(shù)的死鎖不會(huì)這么顯而易見(jiàn),需要仔細(xì)分析代碼才能看出,對(duì)于規(guī)模較大的多線程程序來(lái)說(shuō)尤其如此。好的線程分析工具,例如JProbe Threadalyzer能夠分析死鎖并指出產(chǎn)生問(wèn)題的代碼位置。
隱性死鎖
隱性死鎖由于不規(guī)范的編程方式引起,但不一定每次測(cè)試運(yùn)行時(shí)都會(huì)出現(xiàn)程序死鎖的情形。由于這個(gè)原因,一些隱性死鎖可能要到應(yīng)用正式發(fā)布之后才會(huì)被發(fā)現(xiàn),因此它的危害性比普通死鎖更大。下面介紹兩種導(dǎo)致隱性死鎖的情況:加鎖次序和占有并等待。
加鎖次序
當(dāng)多個(gè)并發(fā)的線程分別試圖同時(shí)占有兩個(gè)鎖時(shí),會(huì)出現(xiàn)加鎖次序沖突的情形。如果一個(gè)線程占有了另一個(gè)線程必需的鎖,就有可能出現(xiàn)死鎖??紤]下面的情形,ThreadA和ThreadB兩個(gè)線程分別需要同時(shí)擁有l(wèi)ock_1、lock_2兩個(gè)鎖,加鎖過(guò)程可能如下:
◆ ThreadA獲得lock_1;
◆ ThreadA被搶占,VM調(diào)度程序轉(zhuǎn)到ThreadB;
◆ ThreadB獲得lock_2;
◆ ThreadB被搶占,VM調(diào)度程序轉(zhuǎn)到ThreadA;
◆ ThreadA試圖獲得lock_2,但lock_2被ThreadB占有,所以ThreadA阻塞;
◆ 調(diào)度程序轉(zhuǎn)到ThreadB;
◆ ThreadB試圖獲得lock_1,但lock_1被ThreadA占有,所以ThreadB阻塞;
◆ ThreadA和ThreadB死鎖。
必須指出的是,在代碼絲毫不做變動(dòng)的情況下,有些時(shí)候上述死鎖過(guò)程不會(huì)出現(xiàn),VM調(diào)度程序可能讓其中一個(gè)線程同時(shí)獲得lock_1和lock_2兩個(gè)鎖,即線程獲取兩個(gè)鎖的過(guò)程沒(méi)有被中斷。在這種情形下,常規(guī)的死鎖檢測(cè)很難確定錯(cuò)誤所在。
占有并等待
如果一個(gè)線程獲得了一個(gè)鎖之后還要等待來(lái)自另一個(gè)線程的通知,可能出現(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向隊(duì)列加入一項(xiàng)新的內(nèi)容后通知Consumer,以便它處理新的內(nèi)容。問(wèn)題在于,Consumer可能保持加在隊(duì)列上的鎖,阻止Producer訪問(wèn)隊(duì)列,甚至在Consumer等待Producer的通知時(shí)也會(huì)繼續(xù)保持鎖。這樣,由于Producer不能向隊(duì)列添加新的內(nèi)容,而Consumer卻在等待Producer加入新內(nèi)容的通知,結(jié)果就導(dǎo)致了死鎖。
在等待時(shí)占有的鎖是一種隱性的死鎖,這是因?yàn)槭虑榭赡馨凑毡容^理想的情況發(fā)展—Producer線程不需要被Consumer占據(jù)的鎖。盡管如此,除非有絕對(duì)可靠的理由肯定Producer線程永遠(yuǎn)不需要該鎖,否則這種編程方式仍是不安全的。有時(shí)“占有并等待”還可能引發(fā)一連串的線程等待,例如,線程A占有線程B需要的鎖并等待,而線程B又占有線程C需要的鎖并等待等。
要改正代碼二的錯(cuò)誤,只需修改Consumer類,把wait()移出“synchronized”()即可。
每個(gè)使用關(guān)系型數(shù)據(jù)庫(kù)的程序都可能遇到數(shù)據(jù)死鎖或不可用的情況,而這些情況需要在代碼中編程來(lái)解決;本文主要介紹與數(shù)據(jù)庫(kù)事務(wù)死鎖等情況相關(guān)的重試邏輯概念,此外,還會(huì)探討如何避免死鎖等問(wèn)題,文章以DB2(版本9)與為例進(jìn)行講解。
什么是數(shù)據(jù)庫(kù)鎖定與死鎖鎖定(Locking)發(fā)生在當(dāng)一個(gè)事務(wù)獲得對(duì)某一資源的“鎖”時(shí),這時(shí),其他的事務(wù)就不能更改這個(gè)資源了,這種機(jī)制的存在是為了保證數(shù)據(jù)一致性;在設(shè)計(jì)與數(shù)據(jù)庫(kù)交互的程序時(shí),必須處理鎖與資源不可用的情況。
鎖定是個(gè)比較復(fù)雜的概念,仔細(xì)說(shuō)起來(lái)可能又需要一大篇,所以在本文中,只把鎖定看作是一個(gè)臨時(shí)事件,這意味著如果一個(gè)資源被鎖定,它總會(huì)在以后某個(gè)時(shí)間被釋放。
而死鎖發(fā)生在當(dāng)多個(gè)進(jìn)程訪問(wèn)同一數(shù)據(jù)庫(kù)時(shí),其中每個(gè)進(jìn)程擁有的鎖都是其他進(jìn)程所需的,由此造成每個(gè)進(jìn)程都無(wú)法繼續(xù)下去。
如何避免鎖我們可利用事務(wù)型數(shù)據(jù)庫(kù)中的隔離級(jí)別機(jī)制來(lái)避免鎖的創(chuàng)建,正確地使用隔離級(jí)別可使程序處理更多的并發(fā)事件(如允許多個(gè)用戶訪問(wèn)數(shù)據(jù)),還能預(yù)防像丟失修改(LostUpdate)、讀“臟”數(shù)據(jù)(DirtyRead)、不可重復(fù)讀(NonrepeatableRead)及“虛”(Phantom)等問(wèn)題。
隔離級(jí)別問(wèn)題現(xiàn)象丟失修改讀“臟”數(shù)據(jù)不可重復(fù)讀“虛”可重復(fù)讀取NoNoNoNo讀取穩(wěn)定性NoNoNoYes光標(biāo)穩(wěn)定性NoNoYesYes未提交的讀NoYesYesYes表1:DB2的隔離級(jí)別與其對(duì)應(yīng)的問(wèn)題現(xiàn)象在只讀模式中,就可以防止鎖定發(fā)生,而不用那些未提交只讀隔離級(jí)別的含糊語(yǔ)句。
浙江電腦培訓(xùn)發(fā)現(xiàn)一條SQL語(yǔ)句當(dāng)使用了下列命令之一時(shí),就應(yīng)該考慮只讀模式了
在基于Java Swing進(jìn)行圖形界面開(kāi)發(fā)的時(shí)候 經(jīng)常遇到的就是Swing多線程問(wèn)題 我們可以想想一下 如果需要在一個(gè)圖形界面上顯示很多數(shù)據(jù) 這些數(shù)據(jù)是經(jīng)過(guò)長(zhǎng)時(shí)間 復(fù)雜的查詢和運(yùn)算得到的 如果在圖形界面的同一個(gè)線程中進(jìn)行查詢和運(yùn)算工作則會(huì)導(dǎo)致一段時(shí)間界面處于死機(jī)狀態(tài) 這會(huì)給用戶帶來(lái)不良的互動(dòng)感受 為了解決這個(gè)問(wèn)題 一般會(huì)單獨(dú)啟動(dòng)一個(gè)線程進(jìn)行運(yùn)算和查詢工作 并隨時(shí)更新圖形界面 這時(shí)候 另一個(gè)問(wèn)題就出現(xiàn)了 可能不僅沒(méi)有解決原來(lái)偶爾死機(jī)問(wèn)題 還可能導(dǎo)致程序徹底死掉 幸運(yùn)的是在JDK中暗藏了一個(gè)中斷程序的快捷鍵 就是CTRL+BREAK 這個(gè)快捷鍵Sun并沒(méi)有在文檔中公布 如果在命令行模式下啟動(dòng)Java程序 然后按CTRL+BREAK鍵 會(huì)得到堆棧的跟蹤信息 從這些跟蹤信息中就可以知道具體引發(fā)死機(jī)的位置了
當(dāng)一個(gè)程序產(chǎn)生死鎖的時(shí)候 你一定會(huì)希望盡快找到原因并且解決它 這時(shí)候 你一般的精力會(huì)用在查找引發(fā)死鎖的位置 另一半的精力會(huì)用于對(duì)堆棧進(jìn)行跟蹤一確定引發(fā)死鎖的原因 但是在Java Swing程序中 你的所有努力可能都是沒(méi)有價(jià)值的 這是因?yàn)镴ava對(duì)Swing的多線程編程有一個(gè)特殊要求 就是在Swing里 只能在與Swing相同的線程里對(duì)GUI元件進(jìn)行修改
也就是說(shuō) 如果你要執(zhí)行類似于jLabel setText( blabla )代碼 必須在Swing線程中 而不允許在其他線程當(dāng)中 如果必須在其他線程中修改元件 可以使用類似一下方式解決
SwingUtilities invokeLater(new Runnable() {
public void run() {
jLabel setText( blabla );
}
}
invokeLater方法雖然表面有時(shí)間延遲執(zhí)行含義 但是實(shí)際上幾乎沒(méi)有任何影響 可能在幾毫秒之內(nèi)就會(huì)被執(zhí)行 另外還有一個(gè)invokeAndWait方法 除非特殊需要 否則幾乎是不用的
在不使用invokeLater的情況下 導(dǎo)致刷新問(wèn)題是可以理解的 但是導(dǎo)致死鎖就優(yōu)點(diǎn)令人匪夷所思了 幸運(yùn)的是 不是任何時(shí)候都需要調(diào)用改方法 這是因?yàn)榇蠖鄶?shù)情況下 我們都是在與Swing同一個(gè)線程里進(jìn)行界面更新 例如監(jiān)聽(tīng)按鈕點(diǎn)擊事件的ActionListener actionPerformed方法就是運(yùn)行在與Swing相同的線程中的 但是如果在回調(diào)類中引用了另一個(gè)類 并且是不屬于AWT/Swing的 那么結(jié)果就很難確定了 所以說(shuō)使用invokeLater應(yīng)該是最安全的
需要注意的是 在invokeLater做的任何事情 都會(huì)導(dǎo)致Swing線程窗口繪制工作暫停下來(lái) 等候invokeLater工作結(jié)束 所以不要在invokeLater進(jìn)行耗時(shí)操作 盡量只執(zhí)行那些界面繪制相關(guān)的工作 可以通過(guò)代碼重構(gòu) 將那些與界面更新相關(guān)的代碼集中起來(lái)統(tǒng)一處理
lishixinzhi/Article/program/Java/gj/201311/27498
主線程保持著A對(duì)象的鎖意思就是主線程正在處理A對(duì)象,其他線程不能處理,要等待主線程結(jié)束之后其他線程才能處理A對(duì)象。
同理副線程正在處理B對(duì)象,A不能處理,所以主線程結(jié)束不了,一直在等待。
兩個(gè)線程都運(yùn)行不下去了就叫做死鎖,程序崩潰。
加鎖的意思就是某線程正在處理某對(duì)象,其他線程不能處理。
手打不容易,明白不明白都給分吧- -、