作者：俞良松

　　在幾乎所有編程語言中，由于多線程引發(fā)的錯誤都有著難以再現(xiàn)的特點，程序的死鎖或其它多線程錯誤可能只在某些特殊的情形下才出現(xiàn)，或在不同的VM上運行同一個程序時錯誤表現(xiàn)不同。因此，在編寫多線程程序時，事先認識和防范可能出現(xiàn)的錯誤特別重要。

　　無論是客戶端還是服務(wù)器端多線程Java程序，最常見的多線程問題包括死鎖、隱性死鎖和數(shù)據(jù)競爭。

　　死鎖

　　死鎖是這樣一種情形：多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由于線程被無限期地阻塞，因此程序不可能正常終止。

　　導(dǎo)致死鎖的根源在于不適當?shù)剡\用“synchronized”關(guān)鍵詞來管理線程對特定對象的訪問�！皊ynchronized”關(guān)鍵詞的作用是，確保在某個時刻只有一個線程被允許執(zhí)行特定的代碼塊，因此，被允許執(zhí)行的線程首先必須擁有對變量或?qū)ο蟮呐潘�性的訪問權(quán)。當線程訪問對象時，線程會給對象加鎖，而這個鎖導(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都被阻塞，程序死鎖。

　　當然，大多數(shù)的死鎖不會這么顯而易見，需要仔細分析代碼才能看出，對于規(guī)模較大的多線程程序來說尤其如此。好的線程分析工具，例如JProbe Threadalyzer能夠分析死鎖并指出產(chǎn)生問題的代碼位置。

　　隱性死鎖

　　隱性死鎖由于不規(guī)范的編程方式引起，但不一定每次測試運行時都會出現(xiàn)程序死鎖的情形。由于這個原因，一些隱性死鎖可能要到應(yīng)用正式發(fā)布之后才會被發(fā)現(xiàn)，因此它的危害性比普通死鎖更大。下面介紹兩種導(dǎo)致隱性死鎖的情況：加鎖次序和占有并等待。

　　加鎖次序

　　當多個并發(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”()即可。

　　數(shù)據(jù)競爭

　　數(shù)據(jù)競爭是由于訪問共享資源（例如變量）時缺乏或不適當?shù)剡\用同步機制引起。如果沒有正確地限定某一時刻某一個線程可以訪問變量，就會出現(xiàn)數(shù)據(jù)競爭，此時贏得競爭的線程獲得訪問許可，但會導(dǎo)致不可預(yù)知的結(jié)果。

　　由于線程的運行可以在任何時候被中斷（即運行機會被其它線程搶占），所以不能假定先開始運行的線程總是比后開始運行的線程先訪問到兩者共享的數(shù)據(jù)。另外，在不同的VM上，線程的調(diào)度方式也可能不同，從而使數(shù)據(jù)競爭問題更加復(fù)雜。

　　有時，數(shù)據(jù)競爭不會影響程序的最終運行結(jié)果，但在另一些時候，有可能導(dǎo)致不可預(yù)料的結(jié)果。

　　良性數(shù)據(jù)競爭

　　并非所有的數(shù)據(jù)競爭都是錯誤�？紤]代碼三的例子。假設(shè)getHouse()向所有的線程返回同一House，可以看出，這里會出現(xiàn)競爭：BrickLayer從House.foundationReady_讀取，而FoundationPourer寫入到House.foundationReady_。

//代碼三
public class House {
public volatile boolean foundationReady_ = false;
}

public class FoundationPourer extends Thread {
public void run() {
  House a = getHouse();
  a.foundationReady_ = true;
}
}

public class BrickLayer extends Thread {
public void run() {
  House a = getHouse();
   while (!a.foundationReady_) {
    try {
     Thread.sleep(500);
    }
    catch (Exception e) {
     System.err.println(“Exception:” + e);
    }
   }
  }
}
}



　　盡管存在競爭，但根據(jù)Java VM規(guī)范，Boolean數(shù)據(jù)的讀取和寫入都是原則性的，也就是說，VM不能中斷線程的讀取或?qū)懭氩僮�。一旦�?shù)據(jù)改動成功，不存在將它改回原來數(shù)據(jù)的必要（不需要“回退”），所以代碼三的數(shù)據(jù)競爭是良性競爭，代碼是安全的。

　　惡性數(shù)據(jù)競爭

　　首先看一下代碼四的例子。

//代碼四
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試圖通過不同的銀行柜員機同時向同一賬戶存錢，會發(fā)生什么事情？讓我們假設(shè)賬戶的初始余額是100元，看看程序的一種可能的執(zhí)行經(jīng)過。

　　B存錢25元，她的柜員機開始執(zhí)行deposit()。首先取得當前余額100，把這個余額保存在本地的臨時變量，然后把臨時變量加25，臨時變量的值變成125。現(xiàn)在，在調(diào)用setBalance()之前，線程調(diào)度器中斷了該線程。

　　A存入50元。當B的線程仍處于掛起狀態(tài)時，A這面開始執(zhí)行deposit()：getBalance()返回100（因為這時B的線程尚未把修改后的余額寫入），A的線程在現(xiàn)有余額的基礎(chǔ)上加50得到150，并把150這個值保存到臨時變量。接著，A的線程在調(diào)用setBalance()之前，也被中斷執(zhí)行。

　　現(xiàn)在，B的線程接著運行，把保存在臨時變量中的值（125）寫入到余額，柜員機告訴B說交易完成，賬戶余額是125元。接下來，A的線程繼續(xù)運行，把臨時變量的值（150）寫入到余額，柜員機告訴A說交易完成，賬戶余額是150元。

　　最后得到的結(jié)果是什么？B的存款消失不見，就像B根本沒有存過錢一樣。

　　也許有人會認為，可以把getBalance()和setBalance()改成同步方法保護Account.balance_，解決數(shù)據(jù)競爭問題。其實這種辦法是行不通的。“synchronized”關(guān)鍵詞可以確保同一時刻只有一個線程執(zhí)行g(shù)etBalance()或setBalance()方法，但這不能在一個線程操作期間阻止另一個線程修改賬戶余額。

要正確運用“synchronized”關(guān)鍵詞，就必須認識到這里要保護的是整個交易過程不被另一個線程干擾，而不僅僅是對數(shù)據(jù)訪問的某一個步驟進行保護。

　　所以，本例的關(guān)鍵是當一個線程獲得當前余額之后，要保證其它的線程不能修改余額，直到第一個線程的余額處理工作全部完成。正確的修改方法是把deposit()和withdraw()改成同步方法。

　　死鎖、隱性死鎖和數(shù)據(jù)競爭是Java多線程編程中最常見的錯誤。要寫出健壯的多線程代碼，正確理解和運用“synchronized”關(guān)鍵詞是很重要的。另外，好的線程分析工具，例如JProbe Threadalyzer，能夠極大地簡化錯誤檢測。對于分析那些不一定每次執(zhí)行時都會出現(xiàn)的錯誤，分析工具尤其有用。