在幾乎所有編程語言中
由於多線程引發的錯誤都有著難以再現的特點
程序的死鎖或其它多線程錯誤可能只在某些特殊的情形下才出現
或在不同的VM上運行同一個程序時錯誤表現不同
因此
在編寫多線程程序時
事先認識和防范可能出現的錯誤特別重要
無論是客戶端還是服務器端多線程Java程序最常見的多線程問題包括死鎖隱性死鎖和數據競爭
一死鎖
死鎖是這樣一種情形多個線程同時被阻塞它們中的一個或者全部都在等待某個資源被釋放由於線程被無限期地阻塞因此程序不可能正常終止
導致死鎖的根源在於不適當地運用synchronized關鍵詞來管理線程對特定對象的訪問synchronized關鍵詞的作用是確保在某個時刻只有一個線程被允許執行特定的代碼塊因此被允許執行的線程首先必須擁有對變量或對象的排他性的訪問權當線程訪問對象時線程會給對象加鎖而這個鎖導致其它也想訪問同一對象的線程被阻塞直至第一個線程釋放它加在對象上的鎖
由於這個原因在使用synchronized關鍵詞時很容易出現兩個線程互相等待對方做出某個動作的情形代碼一是一個導致死鎖的簡單例子
//代碼一
class Deadlocker {
int field_;
private Object lock_ = new int[];
int field_;
private Object lock_ = new int[];
public void method(int value) {
synchronized (lock_) {
synchronized (lock_) {
field_ = ; field_ = ;
}
}
}
public void method(int value) {
synchronized (lock_) {
synchronized (lock_) {
field_ = ; field_ = ;
}
}
}
}
參考代碼一考慮下面的過程
◆ 一個線程（ThreadA）調用method()
◆ ThreadA在lock_上同步但允許被搶先執行
◆ 另一個線程（ThreadB）開始執行
◆ ThreadB調用method()
◆ ThreadB獲得lock_繼續執行企圖獲得lock_但ThreadB不能獲得lock_因為ThreadA占有lock_
◆ 現在ThreadB阻塞因為它在等待ThreadA釋放lock_
◆ 現在輪到ThreadA繼續執行ThreadA試圖獲得lock_但不能成功因為lock_已經被ThreadB占有了
◆ ThreadA和ThreadB都被阻塞程序死鎖
當然大多數的死鎖不會這麼顯而易見需要仔細分析代碼才能看出對於規模較大的多線程程序來說尤其如此好的線程分析工具例如JProbe Threadalyzer能夠分析死鎖並指出產生問題的代碼位置
二隱性死鎖
隱性死鎖由於不規范的編程方式引起但不一定每次測試運行時都會出現程序死鎖的情形由於這個原因一些隱性死鎖可能要到應用正式發布之後才會被發現因此它的危害性比普通死鎖更大下面介紹兩種導致隱性死鎖的情況加鎖次序和占有並等待
加鎖次序
當多個並發的線程分別試圖同時占有兩個鎖時會出現加鎖次序沖突的情形如果一個線程占有了另一個線程必需的鎖就有可能出現死鎖考慮下面的情形ThreadA和ThreadB兩個線程分別需要同時擁有lock_lock_兩個鎖加鎖過程可能如下
◆ ThreadA獲得lock_
◆ ThreadA被搶占VM調度程序轉到ThreadB
◆ ThreadB獲得lock_
◆ ThreadB被搶占VM調度程序轉到ThreadA
◆ ThreadA試圖獲得lock_但lock_被ThreadB占有所以ThreadA阻塞
◆ 調度程序轉到ThreadB
◆ ThreadB試圖獲得lock_但lock_被ThreadA占有所以ThreadB阻塞
◆ ThreadA和ThreadB死鎖
必須指出的是在代碼絲毫不做變動的情況下有些時候上述死鎖過程不會出現VM調度程序可能讓其中一個線程同時獲得lock_和lock_兩個鎖即線程獲取兩個鎖的過程沒有被中斷在這種情形下常規的死鎖檢測很難確定錯誤所在
占有並等待
如果一個線程獲得了一個鎖之後還要等待來自另一個線程的通知可能出現另一種隱性死鎖考慮代碼二
//代碼二
public class queue {
static javalangObject 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的通知時也會繼續保持鎖這樣由於Producer不能向隊列添加新的內容而Consumer卻在等待Producer加入新內容的通知結果就導致了死鎖
在等待時占有的鎖是一種隱性的死鎖這是因為事情可能按照比較理想的情況發展—Producer線程不需要被Consumer占據的鎖盡管如此除非有絕對可靠的理由肯定Producer線程永遠不需要該鎖否則這種編程方式仍是不安全的有時占有並等待還可能引發一連串的線程等待例如線程A占有線程B需要的鎖並等待而線程B又占有線程C需要的鎖並等待等
要改正代碼二的錯誤只需修改Consumer類把wait()移出synchronized()即可
三數據競爭
數據競爭是由於訪問共享資源（例如變量）時缺乏或不適當地運用同步機制引起如果沒有正確地限定某一時刻某一個線程可以訪問變量就會出現數據競爭此時贏得競爭的線程獲得訪問許可但會導致不可預知的結果
由於線程的運行可以在任何時候被中斷（即運行機會被其它線程搶占）所以不能假定先開始運行的線程總是比後開始運行的線程先訪問到兩者共享的數據另外在不同的VM上線程的調度方式也可能不同從而使數據競爭問題更加復雜
有時數據競爭不會影響程序的最終運行結果但在另一些時候有可能導致不可預料的結果
良性數據競爭
並非所有的數據競爭都是錯誤考慮代碼三的例子假設getHouse()向所有的線程返回同一House可以看出這裡會出現競爭BrickLayer從HousefoundationReady_讀取而FoundationPourer寫入到HousefoundationReady_
//代碼三
public class House {
public volatile boolean foundationReady_ = false;
}
public class FoundationPourer extends Thread {
public void run() {
House a = getHouse();
afoundationReady_ = true;
}
}
public class BrickLayer extends Thread {
public void run() {
House a = getHouse();
while (!afoundationReady_) {
try {
Threadsleep();
}
catch (Exception e) {
Systemerrprintln(Exception: + e);
}
}
}
}
}
盡管存在競爭但根據Java VM規范Boolean數據的讀取和寫入都是原則性的也就是說VM不能中斷線程的讀取或寫入操作一旦數據改動成功不存在將它改回原來數據的必要（不需要回退）所以代碼三的數據競爭是良性競爭代碼是安全的
惡性數據競爭
首先看一下代碼四的例子
//代碼四
public class Account {
private int balance_; // 賬戶余額
public int getBalance(void) {
return balance_;
}
public void setBalance(int setting) {
balance_ = setting;
}
}
public class CustomerInfo {
private int numAccounts_;
private Account[] accounts_;
public void withdraw(int accountNumber int amount) {
int temp = accounts_[accountNumber]getBalance();
temp = temp amount;
accounts_[accountNumber]setBalance(temp);
}
public void deposit(int accountNumber int amount) {
int temp = accounts_[accountNumber]getBalance();
temp = temp + amount;
accounts_[accountNumber]setBalance(temp);
}
}
如果丈夫A和妻子B試圖通過不同的銀行櫃員機同時向同一賬戶存錢會發生什麼事情？讓我們假設賬戶的初始余額是元看看程序的一種可能的執行經過
B存錢元她的櫃員機開始執行deposit()首先取得當前余額把這個余額保存在本地的臨時變量然後把臨時變量加臨時變量的值變成現在在調用setBalance()之前線程調度器中斷了該線程
A存入元當B的線程仍處於掛起狀態時A這面開始執行deposit()getBalance()返回（因為這時B的線程尚未把修改後的余額寫入）A的線程在現有余額的基礎上加得到並把這個值保存到臨時變量接著A的線程在調用setBalance()之前也被中斷執行
現在B的線程接著運行把保存在臨時變量中的值（）寫入到余額櫃員機告訴B說交易完成賬戶余額是元接下來A的線程繼續運行把臨時變量的值（）寫入到余額櫃員機告訴A說交易完成賬戶余額是元
最後得到的結果是什麼？B的存款消失不見就像B根本沒有存過錢一樣
也許有人會認為可以把getBalance()和setBalance()改成同步方法保護Accountbalance_解決數據競爭問題其實這種辦法是行不通的synchronized關鍵詞可以確保同一時刻只有一個線程執行getBalance()或setBalance()方法但這不能在一個線程操作期間阻止另一個線程修改賬戶余額
要正確運用synchronized關鍵詞就必須認識到這裡要保護的是整個交易過程不被另一個線程干擾而不僅僅是對數據訪問的某一個步驟進行保護
所以本例的關鍵是當一個線程獲得當前余額之後要保證其它的線程不能修改余額直到第一個線程的余額處理工作全部完成正確的修改方法是把deposit()和withdraw()改成同步方法
死鎖隱性死鎖和數據競爭是Java多線程編程中最常見的錯誤要寫出健壯的多線程代碼正確理解和運用synchronized關鍵詞是很重要的另外好的線程分析工具例如JProbe Threadalyzer能夠極大地簡化錯誤檢測對於分析那些不一定每次執行時都會出現的錯誤分析工具尤其有用
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27782.html
