Java多線程編程的常見陷阱
1、在構(gòu)造函數(shù)中啟動(dòng)線程
我在很多代碼中都看到這樣的問題,在構(gòu)造函數(shù)中啟動(dòng)一個(gè)線程,類似這樣:
- public class A{
- public A(){
- this.x=1;
- this.y=2;
- this.thread=new MyThread();
- this.thread.start();
- }
- }
這個(gè)會(huì)引起什么問題呢?如果有個(gè)類B繼承了類A,依據(jù)java類初始化的順序,A的構(gòu)造函數(shù)一定會(huì)在B的構(gòu)造函數(shù)調(diào)用前被調(diào)用,那么thread線程也將在B被完全初始化之前啟動(dòng),當(dāng)thread運(yùn)行時(shí)使用到了類A中的某些變量,那么就可能使用的不是你預(yù)期中的值,因?yàn)樵贐的構(gòu)造函數(shù)中你可能賦給這些變量新的值。也就是說此時(shí)將有兩個(gè)線程在使用這些變量,而這些變量卻沒有同步。
解決這個(gè)問題有兩個(gè)辦法:將A設(shè)置為final,不可繼承;或者提供單獨(dú)的start方法用來啟動(dòng)線程,而不是放在構(gòu)造函數(shù)中。
2、不完全的同步
都知道對(duì)一個(gè)變量同步的有效方式是用synchronized保護(hù)起來,synchronized可能是對(duì)象鎖,也可能是類鎖,看你是類方法還是實(shí)例方法。但是,當(dāng)你將某個(gè)變量在A方法中同步,那么在變量出現(xiàn)的其他地方,你也需要同步,除非你允許弱可見性甚至產(chǎn)生錯(cuò)誤值。類似這樣的代碼:
- class A{
- int x;
- public int getX(){
- return x;
- }
- public synchronized void setX(int x)
- {
- this.x=x;
- }
- }
x的setter方法有同步,然而getter方法卻沒有,那么就無法保證其他線程通過getX得到的x是***的值。事實(shí)上,這里的setX的同步是沒有必要的,因?yàn)閷?duì)int的寫入是原子的,這一點(diǎn)JVM規(guī)范已經(jīng)保證,多個(gè)同步?jīng)]有任何意義;當(dāng)然,如果這里不是int,而是double或者long,那么getX和setX都將需要同步,因?yàn)閐ouble和long都是64位,寫入和讀取都是分成兩個(gè)32位來進(jìn)行(這一點(diǎn)取決于jvm的實(shí)現(xiàn),有的jvm實(shí)現(xiàn)可能保證對(duì)long和double的read、write是原子的),沒有保證原子性。類似上面這樣的代碼,其實(shí)都可以通過聲明變量為volatile來解決。
3、在使用某個(gè)對(duì)象當(dāng)鎖時(shí),改變了對(duì)象的引用,導(dǎo)致同步失效。
這也是很常見的錯(cuò)誤,類似下面的代碼:
- synchronized(array[0])
- {
- ......
- array[0]=new A();
- ......
- }
同步塊使用array[0]作為鎖,然而在同步塊中卻改變了array[0]指向的引用。分析下這個(gè)場(chǎng)景,***個(gè)線程獲取了array[0]的鎖,第二個(gè)線程因?yàn)闊o法獲取array[0]而等待,在改變了array[0]的引用后,第三個(gè)線程獲取了新的array[0]的鎖,***和第三兩個(gè)線程持有的鎖是不一樣的,同步互斥的目的就完全沒有達(dá)到了。這樣代碼的修改,通常是將鎖聲明為final變量或者引入業(yè)務(wù)無關(guān)的鎖對(duì)象,保證在同步塊內(nèi)不會(huì)被修改引用。
4、沒有在循環(huán)中調(diào)用wait()。
wait和notify用于實(shí)現(xiàn)條件變量,你可能知道需要在同步塊中調(diào)用wait和notify,為了保證條件的改變能做到原子性和可見性。常??匆姾芏啻a做到了同步,卻沒有在循環(huán)中調(diào)用wait,而是使用if甚至沒有條件判斷:
- synchronized(lock)
- {
- if(isEmpty()
- lock.wait();
- }
對(duì)條件的判斷是使用if,這會(huì)造成什么問題呢?在判斷條件之前可能調(diào)用notify或者notifyAll,那么條件已經(jīng)滿足,不會(huì)等待,這沒什么問題。在條件沒有滿足,調(diào)用了wait()方法,釋放lock鎖并進(jìn)入等待休眠狀態(tài)。如果線程是在正常情況下,也就是條件被改變之后被喚醒,那么沒有任何問題,條件滿足繼續(xù)執(zhí)行下面的邏輯操作。問題在于線程可能被意外甚至惡意喚醒,由于沒有再次進(jìn)行條件判斷,在條件沒有被滿足的情況下,線程執(zhí)行了后續(xù)的操作。意外喚醒的情況,可能是調(diào)用了notifyAll,可能是有人惡意喚醒,也可能是很少情況下的自動(dòng)蘇醒(稱為“偽喚醒”)。因此為了防止這種條件沒有滿足就執(zhí)行后續(xù)操作的情況,需要在被喚醒后再次判斷條件,如果條件不滿足,繼續(xù)進(jìn)入等待狀態(tài),條件滿足,才進(jìn)行后續(xù)操作。
- synchronized(lock)
- {
- while(isEmpty()
- lock.wait();
- }
沒有進(jìn)行條件判斷就調(diào)用wait的情況更嚴(yán)重,因?yàn)樵诘却翱赡躰otify已經(jīng)被調(diào)用,那么在調(diào)用了wait之后進(jìn)入等待休眠狀態(tài)后就無法保證線程蘇醒過來。
5、同步的范圍過小或者過大。
同步的范圍過小,可能完全沒有達(dá)到同步的目的;同步的范圍過大,可能會(huì)影響性能。同步范圍過小的一個(gè)常見例子是誤認(rèn)為兩個(gè)同步的方法一起調(diào)用也是將同步的,需要記住的是Atomic+Atomic!=Atomic。
- Map map=Collections.synchronizedMap(new HashMap());
- if(!map.containsKey("a")){
- map.put("a", value);
- }
這是一個(gè)很典型的錯(cuò)誤,map是線程安全的,containskey和put方法也是線程安全的,然而兩個(gè)線程安全的方法被組合調(diào)用就不一定是線程安全的了。因?yàn)樵赾ontainsKey和put之間,可能有其他線程搶先put進(jìn)了a,那么就可能覆蓋了其他線程設(shè)置的值,導(dǎo)致值的丟失。解決這一問題的方法就是擴(kuò)大同步范圍,因?yàn)閷?duì)象鎖是可重入的,因此在線程安全方法之上再同步相同的鎖對(duì)象不會(huì)有問題。
- Map map = Collections.synchronizedMap(new HashMap());
- synchronized (map) {
- if (!map.containsKey("a")) {
- map.put("a", value);
- }
- }
注意,加大鎖的范圍,也要保證使用的是同一個(gè)鎖,不然很可能造成死鎖。 Collections.synchronizedMap(new HashMap())使用的鎖是map本身,因此沒有問題。當(dāng)然,上面的情況現(xiàn)在更推薦使用ConcurrentHashMap,它有putIfAbsent方法來達(dá)到同樣的目的并且滿足線程安全性。
同步范圍過大的例子也很多,比如在同步塊中new大對(duì)象,或者調(diào)用費(fèi)時(shí)的IO操作(操作數(shù)據(jù)庫,webservice等)。不得不調(diào)用費(fèi)時(shí)操作的時(shí)候,一定要指定超時(shí)時(shí)間,例如通過URLConnection去invoke某個(gè)URL時(shí)就要設(shè)置connect timeout和read timeout,防止鎖被獨(dú)占不釋放。同步范圍過大的情況下,要在保證線程安全的前提下,將不必要同步的操作從同步塊中移出。
6、正確使用volatile
在jdk5修正了volatile的語義后,volatile作為一種輕量級(jí)的同步策略就得到了大量的使用。volatile的嚴(yán)格定義參考jvm spec,這里只從volatile能做什么,和不能用來做什么出發(fā)做個(gè)探討。
volatile可以用來做什么?
1)狀態(tài)標(biāo)志,模擬控制機(jī)制。常見用途如控制線程是否停止:
- private volatile boolean stopped;
- public void close(){
- stopped=true;
- }
- public void run(){
- while(!stopped){
- //do something
- }
- }
前提是do something中不會(huì)有阻塞調(diào)用之類。volatile保證stopped變量的可見性,run方法中讀取stopped變量總是main memory中的***值。
2)安全發(fā)布,如修復(fù)DLC問題。
- private volatile IoBufferAllocator instance;
- public IoBufferAllocator getInsntace(){
- if(instance==null){
- synchronized (IoBufferAllocator.class) {
- if(instance==null)
- instance=new IoBufferAllocator();
- }
- }
- return instance;
- }
3)開銷較低的讀寫鎖
- public class CheesyCounter {
- private volatile int value;
- public int getValue() { return value; }
- public synchronized int increment() {
- return value++;
- }
- }
synchronized保證更新的原子性,volatile保證線程間的可見性。
volatile不能用于做什么?
1)不能用于做計(jì)數(shù)器
- public class CheesyCounter {
- private volatile int value;
- public int getValue() { return value; }
- public int increment() {
- return value++;
- }
- }
因?yàn)関alue++其實(shí)是有三個(gè)操作組成的:讀取、修改、寫入,volatile不能保證這個(gè)序列是原子的。對(duì)value的修改操作依賴于value的***值。解決這個(gè)問題的方法可以將increment方法同步,或者使用AtomicInteger原子類。
2)與其他變量構(gòu)成不變式
一個(gè)典型的例子是定義一個(gè)數(shù)據(jù)范圍,需要保證約束lower< upper。
- public class NumberRange {
- private volatile int lower, upper;
- public int getLower() { return lower; }
- public int getUpper() { return upper; }
- public void setLower(int value) {
- if (value > upper)
- throw new IllegalArgumentException();
- lower = value;
- }
- public void setUpper(int value) {
- if (value < lower)
- throw new IllegalArgumentException();
- upper = value;
- }
- }
盡管講lower和upper聲明為volatile,但是setLower和setUpper并不是線程安全方法。假設(shè)初始狀態(tài)為(0,5),同時(shí)調(diào)用setLower(4)和setUpper(3),兩個(gè)線程交叉進(jìn)行,***結(jié)果可能是(4,3),違反了約束條件。修改這個(gè)問題的辦法就是將setLower和setUpper同步:
- public class NumberRange {
- private volatile int lower, upper;
- public int getLower() { return lower; }
- public int getUpper() { return upper; }
- public synchronized void setLower(int value) {
- if (value > upper)
- throw new IllegalArgumentException();
- lower = value;
- }
- public synchronized void setUpper(int value) {
- if (value < lower)
- throw new IllegalArgumentException();
- upper = value;
- }
- }
【編輯推薦】