南寧達(dá)內(nèi)：編寫多線程Java應(yīng)用程序常見問題

幾乎所有使用AWT或Swing編寫的畫圖程序都需要多線程。但多線程程序會造成許多困難，剛開始編程的開發(fā)者常常會發(fā)現(xiàn)他們被一些問題所折磨，例如不正確的程序行為或死鎖。

在本文中，我們將探討使用多線程時(shí)遇到的問題，并提出那些常見陷阱的解決方案。

線程是什么？

一個(gè)程序或進(jìn)程能夠包含多個(gè)線程，這些線程可以根據(jù)程序的代碼執(zhí)行相應(yīng)的指令。多線程看上去似乎在并行執(zhí)行它們各自的工作，就像在一臺計(jì)算機(jī)上運(yùn)行著多個(gè)處理機(jī)一樣。在多處理機(jī)計(jì)算機(jī)上實(shí)現(xiàn)多線程時(shí)，它們確實(shí)可以并行工作。和進(jìn)程不同的是，線程共享地址空間。也就是說，多個(gè)線程能夠讀寫相同的變量或數(shù)據(jù)結(jié)構(gòu)。

編寫多線程程序時(shí)，你必須注意每個(gè)線程是否干擾了其他線程的工作?？梢詫⒊绦蚩醋饕粋€(gè)辦公室，如果不需要共享辦公室資源或與其他人交流，所有職員就會獨(dú)立并行地工作。某個(gè)職員若要和其他人交談，當(dāng)且僅當(dāng)該職員在“聽”且他們兩說同樣的語言。此外，只有在復(fù)印機(jī)空閑且處于可用狀態(tài)(沒有僅完成一半的復(fù)印工作，沒有紙張阻塞等問題)時(shí)，職員才能夠使用它。在這篇文章中你將看到，在Java程序中互相協(xié)作的線程就好像是在一個(gè)組織良好的機(jī)構(gòu)中工作的職員。

在多線程程序中，線程可以從準(zhǔn)備就緒隊(duì)列中得到，并在可獲得的系統(tǒng)CPU上運(yùn)行。操作系統(tǒng)可以將線程從處理器移到準(zhǔn)備就緒隊(duì)列或阻塞隊(duì)列中，這種情況可以認(rèn)為是處理器“掛起”了該線程。同樣，Java虛擬機(jī)(JVM)也可以控制線程的移動(dòng)--在協(xié)作或搶先模型中--從準(zhǔn)備就緒隊(duì)列中將進(jìn)程移到處理器中，于是該線程就可以開始執(zhí)行它的程序代碼。

協(xié)作式線程模型允許線程自己決定什么時(shí)候放棄處理器來等待其他的線程。程序開發(fā)員可以精確地決定某個(gè)線程何時(shí)會被其他線程掛起，允許它們與對方有效地合作。缺點(diǎn)在于某些惡意或是寫得不好的線程會消耗所有可獲得的CPU時(shí)間，導(dǎo)致其他線程“饑餓”.

在搶占式線程模型中，操作系統(tǒng)可以在任何時(shí)候打斷線程。通常會在它運(yùn)行了一段時(shí)間(就是所謂的一個(gè)時(shí)間片)后才打斷它。這樣的結(jié)果自然是沒有線程能夠不公平地長時(shí)間霸占處理器。然而，隨時(shí)可能打斷線程就會給程序開發(fā)員帶來其他麻煩。同樣使用辦公室的例子，假設(shè)某個(gè)職員搶在另一人前使用復(fù)印機(jī)，但打印工作在未完成的時(shí)候離開了，另一人接著使用復(fù)印機(jī)時(shí)，該復(fù)印機(jī)上可能就還有先前那名職員留下來的資料。搶占式線程模型要求線程正確共享資源，協(xié)作式模型卻要求線程共享執(zhí)行時(shí)間。由于JVM規(guī)范并沒有特別規(guī)定線程模型，Java開發(fā)員必須編寫可在兩種模型上正確運(yùn)行的程序。在了解線程以及線程間通訊的一些方面之后，我們可以看到如何為這兩種模型設(shè)計(jì)程序。

線程和Java語言

為了使用Java語言創(chuàng)建線程，你可以生成一個(gè)Thread類(或其子類)的對象，并給這個(gè)對象發(fā)送start()消息。(程序可以向任何一個(gè)派生自Runnable接口的類對象發(fā)送start()消息。)每個(gè)線程動(dòng)作的定義包含在該線程對象的run()方法中。run方法就相當(dāng)于傳統(tǒng)程序中的main()方法;線程會持續(xù)運(yùn)行，直到run()返回為止，此時(shí)該線程便死了。

上鎖

大多數(shù)應(yīng)用程序要求線程互相通信來同步它們的動(dòng)作。在Java程序中最簡單實(shí)現(xiàn)同步的方法就是上鎖。為了防止同時(shí)訪問共享資源，線程在使用資源的前后可以給該資源上鎖和開鎖。假想給復(fù)印機(jī)上鎖，任一時(shí)刻只有一個(gè)職員擁有鑰匙。若沒有鑰匙就不能使用復(fù)印機(jī)。給共享變量上鎖就使得Java線程能夠快速方便地通信和同步。某個(gè)線程若給一個(gè)對象上了鎖，就可以知道沒有其他線程能夠訪問該對象。即使在搶占式模型中，其他線程也不能夠訪問此對象，直到上鎖的線程被喚醒、完成工作并開鎖。那些試圖訪問一個(gè)上鎖對象的線程通常會進(jìn)入睡眠狀態(tài)，直到上鎖的線程開鎖。一旦鎖被打開，這些睡眠進(jìn)程就會被喚醒并移到準(zhǔn)備就緒隊(duì)列中。

在Java編程中，所有的對象都有鎖。線程可以使用synchronized關(guān)鍵字來獲得鎖。在任一時(shí)刻對于給定的類的實(shí)例，方法或同步的代碼塊只能被一個(gè)線程執(zhí)行。這是因?yàn)榇a在執(zhí)行之前要求獲得對象的鎖。繼續(xù)我們關(guān)于復(fù)印機(jī)的比喻，為了避免復(fù)印沖突，我們可以簡單地對復(fù)印資源實(shí)行同步。如同下列的代碼例子，任一時(shí)刻只允許一位職員使用復(fù)印資源。通過使用方法(在Copier對象中)來修改復(fù)印機(jī)狀態(tài)。這個(gè)方法就是同步方法。只有一個(gè)線程能夠執(zhí)行一個(gè)Copier對象中同步代碼，因此那些需要使用Copier對象的職員就必須排隊(duì)等候。

classCopyMachine{

publicsynchronizedvoidmakeCopies(Documentd,intnCopies){

//onlyonethreadexecutesthisatatime

}

publicvoidloadPaper(){

//multiplethreadscouldaccessthisatonce!

synchronized(this){

//onlyonethreadaccessesthisatatime

//feelfreetousesharedresources,overwritemembers,etc.

}

}

}

Fine-grain鎖

在對象級使用鎖通常是一種比較粗糙的方法。為什么要將整個(gè)對象都上鎖，而不允許其他線程短暫地使用對象中其他同步方法來訪問共享資源？如果一個(gè)對象擁有多個(gè)資源，就不需要只為了讓一個(gè)線程使用其中一部分資源，就將所有線程都鎖在外面。由于每個(gè)對象都有鎖，可以如下所示使用虛擬對象來上鎖：

classFineGrainLock{

MyMemberClassx,y;

Objectxlock=newObject()，ylock=newObject();

publicvoidfoo(){

synchronized(xlock){

//accessxhere

}

//dosomethinghere-butdon'tusesharedresources

synchronized(ylock){

//accessyhere

}

}

publicvoidbar(){

synchronized(this){

//accessbothxandyhere

}

//dosomethinghere-butdon'tusesharedresources

}

}

若為了在方法級上同步，不能將整個(gè)方法聲明為synchronized關(guān)鍵字。它們使用的是成員鎖，而不是synchronized方法能夠獲得的對象級鎖。

信號量

通常情況下，可能有多個(gè)線程需要訪問數(shù)目很少的資源。假想在服務(wù)器上運(yùn)行著若干個(gè)回答客戶端請求的線程。這些線程需要連接到同一數(shù)據(jù)庫，但任一時(shí)刻只能獲得一定數(shù)目的數(shù)據(jù)庫連接。你要怎樣才能夠有效地將這些固定數(shù)目的數(shù)據(jù)庫連接分配給大量的線程？一種控制訪問一組資源的方法(除了簡單地上鎖之外)，就是使用眾所周知的信號量計(jì)數(shù)(countingsemaphore)。信號量計(jì)數(shù)將一組可獲得資源的管理封裝起來。信號量是在簡單上鎖的基礎(chǔ)上實(shí)現(xiàn)的，相當(dāng)于能令線程安全執(zhí)行，并初始化為可用資源個(gè)數(shù)的計(jì)數(shù)器。例如我們可以將一個(gè)信號量初始化為可獲得的數(shù)據(jù)庫連接個(gè)數(shù)。一旦某個(gè)線程獲得了信號量，可獲得的數(shù)據(jù)庫連接數(shù)減一。線程消耗完資源并釋放該資源時(shí)，計(jì)數(shù)器就會加一。當(dāng)信號量控制的所有資源都已被占用時(shí)，若有線程試圖訪問此信號量，則會進(jìn)入阻塞狀態(tài)，直到有可用資源被釋放。

信號量最常見的用法是解決“消費(fèi)者-生產(chǎn)者問題”.當(dāng)一個(gè)線程進(jìn)行工作時(shí)，若另外一個(gè)線程訪問同一共享變量，就可能產(chǎn)生此問題。消費(fèi)者線程只能在生產(chǎn)者線程完成生產(chǎn)后才能夠訪問數(shù)據(jù)。使用信號量來解決這個(gè)問題，就需要?jiǎng)?chuàng)建一個(gè)初始化為零的信號量，從而讓消費(fèi)者線程訪問此信號量時(shí)發(fā)生阻塞。每當(dāng)完成單位工作時(shí)，生產(chǎn)者線程就會向該信號量發(fā)信號(釋放資源)。每當(dāng)消費(fèi)者線程消費(fèi)了單位生產(chǎn)結(jié)果并需要新的數(shù)據(jù)單元時(shí)，它就會試圖再次獲取信號量。因此信號量的值就總是等于生產(chǎn)完畢可供消費(fèi)的數(shù)據(jù)單元數(shù)。這種方法比采用消費(fèi)者線程不停檢查是否有可用數(shù)據(jù)單元的方法要高效得多。因?yàn)橄M(fèi)者線程醒來后，倘若沒有找到可用的數(shù)據(jù)單元，就會再度進(jìn)入睡眠狀態(tài)，這樣的操作系統(tǒng)開銷是非常昂貴的。

盡管信號量并未直接被Java語言所支持，卻很容易在給對象上鎖的基礎(chǔ)上實(shí)現(xiàn)。一個(gè)簡單的實(shí)現(xiàn)方法如下所示：

classSemaphore{

privateintcount;

publicSemaphore(intn){

this.count=n;

}

publicsynchronizedvoidacquire(){

while(count==0){

try{

wait();

}catch(InterruptedExceptione){

//keeptrying

}

}

count--;

}

publicsynchronizedvoidrelease(){

count++;

notify();//alertathreadthat'sblockingonthissemaphore

}

}

常見的上鎖問題

不幸的是，使用上鎖會帶來其他問題。讓我們來看一些常見問題以及相應(yīng)的解決方法：

死鎖。死鎖是一個(gè)經(jīng)典的多線程問題，因?yàn)椴煌木€程都在等待那些根本不可能被釋放的鎖，從而導(dǎo)致所有的工作都無法完成。假設(shè)有兩個(gè)線程，分別代表兩個(gè)饑餓的人，他們必須共享刀叉并輪流吃飯。他們都需要獲得兩個(gè)鎖：共享刀和共享叉的鎖。假如線程“A”獲得了刀，而線程“B”獲得了叉。線程A就會進(jìn)入阻塞狀態(tài)來等待獲得叉，而線程B則阻塞來等待A所擁有的刀。這只是人為設(shè)計(jì)的例子，但盡管在運(yùn)行時(shí)很難探測到，這類情況卻時(shí)常發(fā)生。雖然要探測或推敲各種情況是非常困難的，但只要按照下面幾條規(guī)則去設(shè)計(jì)系統(tǒng)，就能夠避免死鎖問題：

讓所有的線程按照同樣的順序獲得一組鎖。這種方法消除了X和Y的擁有者分別等待對方的資源的問題。

將多個(gè)鎖組成一組并放到同一個(gè)鎖下。前面死鎖的例子中，可以創(chuàng)建一個(gè)銀器對象的鎖。于是在獲得刀或叉之前都必須獲得這個(gè)銀器的鎖。

將那些不會阻塞的可獲得資源用變量標(biāo)志出來。當(dāng)某個(gè)線程獲得銀器對象的鎖時(shí)，就可以通過檢查變量來判斷是否整個(gè)銀器集合中的對象鎖都可獲得。如果是，它就可以獲得相關(guān)的鎖，否則，就要釋放掉銀器這個(gè)鎖并稍后再嘗試。

最重要的是，在編寫代碼前認(rèn)真仔細(xì)地設(shè)計(jì)整個(gè)系統(tǒng)。多線程是困難的，在開始編程之前詳細(xì)設(shè)計(jì)系統(tǒng)能夠幫助你避免難以發(fā)現(xiàn)死鎖的問題。

Volatile變量。volatile關(guān)鍵字是Java語言為優(yōu)化編譯器設(shè)計(jì)的。以下面的代碼為例：

classVolatileTest{

publicvoidfoo(){

booleanflag=false;

if(flag){

//thiscouldhappen

}

}

}

一個(gè)優(yōu)化的編譯器可能會判斷出if部分的語句永遠(yuǎn)不會被執(zhí)行，就根本不會編譯這部分的代碼。如果這個(gè)類被多線程訪問，flag被前面某個(gè)線程設(shè)置之后，在它被if語句測試之前，可以被其他線程重新設(shè)置。用volatile關(guān)鍵字來聲明變量，就可以告訴編譯器在編譯的時(shí)候，不需要通過預(yù)測變量值來優(yōu)化這部分的代碼。

無法訪問的線程有時(shí)候雖然獲取對象鎖沒有問題，線程依然有可能進(jìn)入阻塞狀態(tài)。在Java編程中IO就是這類問題最好的例子。當(dāng)線程因?yàn)閷ο髢?nèi)的IO調(diào)用而阻塞時(shí)，此對象應(yīng)當(dāng)仍能被其他線程訪問。該對象通常有責(zé)任取消這個(gè)阻塞的IO操作。造成阻塞調(diào)用的線程常常會令同步任務(wù)失敗。如果該對象的其他方法也是同步的，當(dāng)線程被阻塞時(shí)，此對象也就相當(dāng)于被冷凍住了。其他的線程由于不能獲得對象的鎖，就不能給此對象發(fā)消息(例如，取消IO操作)。必須確保不在同步代碼中包含那些阻塞調(diào)用，或確認(rèn)在一個(gè)用同步阻塞代碼的對象中存在非同步方法。盡管這種方法需要花費(fèi)一些注意力來保證結(jié)果代碼安全運(yùn)行，但它允許在擁有對象的線程發(fā)生阻塞后，該對象仍能夠響應(yīng)其他線程。

為不同的線程模型進(jìn)行設(shè)計(jì)

判斷是搶占式還是協(xié)作式的線程模型，取決于虛擬機(jī)的實(shí)現(xiàn)者，并根據(jù)各種實(shí)現(xiàn)而不同。因此，Java開發(fā)員必須編寫那些能夠在兩種模型上工作的程序。

正如前面所提到的，在搶占式模型中線程可以在代碼的任何一個(gè)部分的中間被打斷，除非那是一個(gè)原子操作代碼塊。原子操作代碼塊中的代碼段一旦開始執(zhí)行，就要在該線程被換出處理器之前執(zhí)行完畢。在Java編程中，分配一個(gè)小于32位的變量空間是一種原子操作，而此外象double和long這兩個(gè)64位數(shù)據(jù)類型的分配就不是原子的。使用鎖來正確同步共享資源的訪問，就足以保證一個(gè)多線程程序在搶占式模型下正確工作。

而在協(xié)作式模型中，是否能保證線程正常放棄處理器，不掠奪其他線程的執(zhí)行時(shí)間，則完全取決于程序員。調(diào)用yield()方法能夠?qū)?dāng)前的線程從處理器中移出到準(zhǔn)備就緒隊(duì)列中。另一個(gè)方法則是調(diào)用sleep()方法，使線程放棄處理器，并且在sleep方法中指定的時(shí)間間隔內(nèi)睡眠。

正如你所想的那樣，將這些方法隨意放在代碼的某個(gè)地方，并不能夠保證正常工作。如果線程正擁有一個(gè)鎖(因?yàn)樗谝粋€(gè)同步方法或代碼塊中)，則當(dāng)它調(diào)用yield()時(shí)不能夠釋放這個(gè)鎖。這就意味著即使這個(gè)線程已經(jīng)被掛起，等待這個(gè)鎖釋放的其他線程依然不能繼續(xù)運(yùn)行。為了緩解這個(gè)問題，最好不在同步方法中調(diào)用yield方法。將那些需要同步的代碼包在一個(gè)同步塊中，里面不含有非同步的方法，并且在這些同步代碼塊之外才調(diào)用yield.

另外一個(gè)解決方法則是調(diào)用wait()方法，使處理器放棄它當(dāng)前擁有的對象的鎖。如果對象在方法級別上使同步的，這種方法能夠很好的工作。因?yàn)樗鼉H僅使用了一個(gè)鎖。如果它使用fine-grained鎖，則wait()將無法放棄這些鎖。此外，一個(gè)因?yàn)檎{(diào)用wait()方法而阻塞的線程，只有當(dāng)其他線程調(diào)用notifyAll()時(shí)才會被喚醒。

線程和AWT/Swing

在那些使用Swing和/或AWT包創(chuàng)建GUI(用戶圖形界面)的Java程序中，AWT事件句柄在它自己的線程中運(yùn)行。開發(fā)員必須注意避免將這些GUI線程與較耗時(shí)間的計(jì)算工作綁在一起，因?yàn)檫@些線程必須負(fù)責(zé)處理用戶時(shí)間并重繪用戶圖形界面。換句話來說，一旦GUI線程處于繁忙，整個(gè)程序看起來就象無響應(yīng)狀態(tài)。Swing線程通過調(diào)用合適方法，通知那些Swingcallback(例如MouseListener和ActionListener)。這種方法意味著listener無論要做多少事情，都應(yīng)當(dāng)利用listenercallback方法產(chǎn)生其他線程來完成此項(xiàng)工作。目的便在于讓listenercallback更快速返回，從而允許Swing線程響應(yīng)其他事件。

如果一個(gè)Swing線程不能夠同步運(yùn)行、響應(yīng)事件并重繪輸出，那怎么能夠讓其他的線程安全地修改Swing的狀態(tài)？正如上面提到的，Swingcallback在Swing線程中運(yùn)行。因此他們能修改Swing數(shù)據(jù)并繪到屏幕上。

但是如果不是Swingcallback產(chǎn)生的變化該怎么辦呢？使用一個(gè)非Swing線程來修改Swing數(shù)據(jù)是不安全的。Swing提供了兩個(gè)方法來解決這個(gè)問題：invokeLater()和invokeAndWait()。為了修改Swing狀態(tài)，只要簡單地調(diào)用其中一個(gè)方法，讓Runnable的對象來做這些工作。因?yàn)镽unnable對象通常就是它們自身的線程，你可能會認(rèn)為這些對象會作為線程來執(zhí)行。但那樣做其實(shí)也是不安全的。事實(shí)上，Swing會將這些對象放到隊(duì)列中，并在將來某個(gè)時(shí)刻執(zhí)行它的run方法。這樣才能夠安全修改Swing狀態(tài)。

總結(jié)

Java語言的設(shè)計(jì)，使得多線程對幾乎所有的Applet都是必要的。特別是，IO和GUI編程都需要多線程來為用戶提供完美的體驗(yàn)。如果依照本文所提到的若干基本規(guī)則，并在開始編程前仔細(xì)設(shè)計(jì)系統(tǒng)--包括它對共享資源的訪問等，你就可以避免許多常見和難以發(fā)覺的線程陷阱。