在 IBM Bluemix 云平臺上開發(fā)并部署您的下一個應(yīng)用。
創(chuàng)新互聯(lián)公司專注于博愛網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供博愛營銷型網(wǎng)站建設(shè)，博愛網(wǎng)站制作、博愛網(wǎng)頁設(shè)計、博愛網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù)，打造博愛網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供博愛網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
開始您的試用
Java 語言通過 synchronized 關(guān)鍵字來保證原子性，這是因為每一個 Object 都有一個隱含的鎖，這個也稱作監(jiān)視器對象。在進入 synchronized 之前自動獲取此內(nèi)部鎖，而一旦離開此方式，無論是完成或者中斷都會自動釋放鎖。顯然這是一個獨占鎖，每個鎖請求之間是互斥的。相對于眾多高級鎖 (Lock/ReadWriteLock 等)，synchronized 的代價都比后者要高。但是 synchronzied 的語法比較簡單，而且也比較容易使用和理解。Lock 一旦調(diào)用了 lock() 方法獲取到鎖而未正確釋放的話很有可能造成死鎖，所以 Lock 的釋放操作總是跟在 finally 代碼塊里面，這在代碼結(jié)構(gòu)上也是一次調(diào)整和冗余。Lock 的實現(xiàn)已經(jīng)將硬件資源用到了極致，所以未來可優(yōu)化的空間不大，除非硬件有了更高的性能，但是 synchronized 只是規(guī)范的一種實現(xiàn)，這在不同的平臺不同的硬件還有很高的提升空間，未來 Java 鎖上的優(yōu)化也會主要在這上面。既然 synchronzied 都不可能避免死鎖產(chǎn)生，那么死鎖情況會是經(jīng)常容易出現(xiàn)的錯誤，下面具體描述死鎖發(fā)生的原因及解決方法。
死鎖描述
死鎖是操作系統(tǒng)層面的一個錯誤，是進程死鎖的簡稱，最早在 1965 年由 Dijkstra 在研究銀行家算法時提出的，它是計算機操作系統(tǒng)乃至整個并發(fā)程序設(shè)計領(lǐng)域最難處理的問題之一。
事實上，計算機世界有很多事情需要多線程方式去解決，因為這樣才能最大程度上利用資源，才能體現(xiàn)出計算的高效。但是，實際上來說，計算機系統(tǒng)中有很多一次只能由一個進程使用的資源的情況，例如打印機，同時只能有一個進程控制它。在多通道程序設(shè)計環(huán)境中，若干進程往往要共享這類資源，而且一個進程所需要的資源還很有可能不止一個。因此，就會出現(xiàn)若干進程競爭有限資源，又推進順序不當(dāng)，從而構(gòu)成無限期循環(huán)等待的局面。我們稱這種狀態(tài)為死鎖。簡單一點描述，死鎖是指多個進程循環(huán)等待它方占有的資源而無限期地僵持下去的局面。很顯然，如果沒有外力的作用，那么死鎖涉及到的各個進程都將永遠處于封鎖狀態(tài)。
系統(tǒng)發(fā)生死鎖現(xiàn)象不僅浪費大量的系統(tǒng)資源，甚至導(dǎo)致整個系統(tǒng)崩潰，帶來災(zāi)難性后果。所以，對于死鎖問題在理論上和技術(shù)上都必須予以高度重視。
銀行家算法
一個銀行家如何將一定數(shù)目的資金安全地借給若干個客戶，使這些客戶既能借到錢完成要干的事，同時銀行家又能收回全部資金而不至于破產(chǎn)。銀行家就像一個操作系統(tǒng)，客戶就像運行的進程，銀行家的資金就是系統(tǒng)的資源。
銀行家算法需要確保以下四點：
當(dāng)一個顧客對資金的最大需求量不超過銀行家現(xiàn)有的資金時就可接納該顧客；
顧客可以分期貸款, 但貸款的總數(shù)不能超過最大需求量；
當(dāng)銀行家現(xiàn)有的資金不能滿足顧客尚需的貸款數(shù)額時，對顧客的貸款可推遲支付，但總能使顧客在有限的時間里得到貸款；
當(dāng)顧客得到所需的全部資金后，一定能在有限的時間里歸還所有的資金。
線程的同步只對方法有效，如果一個線程正在調(diào)用該方法的時候，另一個線程也需要訪問該方法，如果用了synchronized 的關(guān)鍵字的，后來的線程就必需等前面的線程執(zhí)行方法完畢后才開始調(diào)用該方法，如果沒有用synchronized 關(guān)鍵字，就有可能出現(xiàn)死鎖狀態(tài)。建議你去看看線程相關(guān)的知識。
引用“如果不想讓其他線程對b進行操作，要怎么寫呢？” 如果不想讓其他線程對b進行操作，就不調(diào)用b就可以了
死鎖是這樣一種情形：多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由于線程被無限期地阻塞，因此程序不可能正常終止。
導(dǎo)致死鎖的根源在于不適當(dāng)?shù)剡\用“synchronized”關(guān)鍵詞來管理線程對特定對象的訪問?！皊ynchronized”關(guān)鍵詞的作用是，確保在某個時刻只有一個線程被允許執(zhí)行特定的代碼塊，因此，被允許執(zhí)行的線程首先必須擁有對變量或?qū)ο蟮呐潘缘脑L問權(quán)。當(dāng)線程訪問對象時，線程會給對象加鎖，而這個鎖導(dǎo)致其它也想訪問同一對象的線程被阻塞，直至第一個線程釋放它加在對象上的鎖。
由于這個原因，在使用“synchronized”關(guān)鍵詞時，很容易出現(xiàn)兩個線程互相等待對方做出某個動作的情形。代碼一是一個導(dǎo)致死鎖的簡單例子。
//代碼一
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）調(diào)用method1()。
◆ ThreadA在lock_1上同步，但允許被搶先執(zhí)行。
◆ 另一個線程（ThreadB）開始執(zhí)行。
◆ ThreadB調(diào)用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都被阻塞，程序死鎖。
當(dāng)然，大多數(shù)的死鎖不會這么顯而易見，需要仔細分析代碼才能看出，對于規(guī)模較大的多線程程序來說尤其如此。好的線程分析工具，例如JProbe Threadalyzer能夠分析死鎖并指出產(chǎn)生問題的代碼位置。
隱性死鎖
隱性死鎖由于不規(guī)范的編程方式引起，但不一定每次測試運行時都會出現(xiàn)程序死鎖的情形。由于這個原因，一些隱性死鎖可能要到應(yīng)用正式發(fā)布之后才會被發(fā)現(xiàn)，因此它的危害性比普通死鎖更大。下面介紹兩種導(dǎo)致隱性死鎖的情況：加鎖次序和占有并等待。
加鎖次序
當(dāng)多個并發(fā)的線程分別試圖同時占有兩個鎖時，會出現(xiàn)加鎖次序沖突的情形。如果一個線程占有了另一個線程必需的鎖，就有可能出現(xiàn)死鎖?？紤]下面的情形，ThreadA和ThreadB兩個線程分別需要同時擁有l(wèi)ock_1、lock_2兩個鎖，加鎖過程可能如下：
◆ 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死鎖。
必須指出的是，在代碼絲毫不做變動的情況下，有些時候上述死鎖過程不會出現(xiàn)，VM調(diào)度程序可能讓其中一個線程同時獲得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向隊列加入一項新的內(nèi)容后通知Consumer，以便它處理新的內(nèi)容。問題在于，Consumer可能保持加在隊列上的鎖，阻止Producer訪問隊列，甚至在Consumer等待Producer的通知時也會繼續(xù)保持鎖。這樣，由于Producer不能向隊列添加新的內(nèi)容，而Consumer卻在等待Producer加入新內(nèi)容的通知，結(jié)果就導(dǎo)致了死鎖。
在等待時占有的鎖是一種隱性的死鎖，這是因為事情可能按照比較理想的情況發(fā)展—Producer線程不需要被Consumer占據(jù)的鎖。盡管如此，除非有絕對可靠的理由肯定Producer線程永遠不需要該鎖，否則這種編程方式仍是不安全的。有時“占有并等待”還可能引發(fā)一連串的線程等待，例如，線程A占有線程B需要的鎖并等待，而線程B又占有線程C需要的鎖并等待等。
要改正代碼二的錯誤，只需修改Consumer類，把wait()移出“synchronized”()即可。
line = bufferedReader.readLine();//死鎖位置
會等待，所以會。
用另一個線程讀、主線程檢測是否命令終止了。
重慶分公司
重慶分公司
