<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    莊周夢蝶

    生活、程序、未來
       :: 首頁 ::  ::  :: 聚合  :: 管理

    java多線程編程的常見陷阱

    Posted on 2009-04-25 12:21 dennis 閱讀(3202) 評論(2)  編輯  收藏 所屬分類: java

    1、在構造函數中啟動線程
         我在很多代碼中都看到這樣的問題,在構造函數中啟動一個線程,類似這樣:
    public class A{
       
    public A(){
          
    this.x=1;
          
    this.y=2;
          
    this.thread=new MyThread();
          
    this.thread.start();
       }
       
    }
       這個會引起什么問題呢?如果有個類B繼承了類A,依據java類初始化的順序,A的構造函數一定會在B的構造函數調用前被調用,那么thread線程也將在B被完全初始化之前啟動,當thread運行時使用到了類A中的某些變量,那么就可能使用的不是你預期中的值,因為在B的構造函數中你可能賦給這些變量新的值。也就是說此時將有兩個線程在使用這些變量,而這些變量卻沒有同步。
       解決這個問題有兩個辦法:將A設置為final,不可繼承;或者提供單獨的start方法用來啟動線程,而不是放在構造函數中。

    2、不完全的同步
      
    都知道對一個變量同步的有效方式是用synchronized保護起來,synchronized可能是對象鎖,也可能是類鎖,看你是類方法還是實例方法。但是,當你將某個變量在A方法中同步,那么在變量出現的其他地方,你也需要同步,除非你允許弱可見性甚至產生錯誤值。類似這樣的代碼:
    class A{
      
    int x;
      
    public int getX(){
         
    return x;
      }
      
    public synchronized void setX(int x)
      {
         
    this.x=x;
      }
    }
        x的setter方法有同步,然而getter方法卻沒有,那么就無法保證其他線程通過getX得到的x是最新的值。事實上,這里的setX的同步是沒有必要的,因為對int的寫入是原子的,這一點JVM規范已經保證,多個同步沒有任何意義;當然,如果這里不是int,而是double或者long,那么getX和setX都將需要同步,因為double和long都是64位,寫入和讀取都是分成兩個32位來進行(這一點取決于jvm的實現,有的jvm實現可能保證對long和double的read、write是原子的),沒有保證原子性。類似上面這樣的代碼,其實都可以通過聲明變量為volatile來解決。
      
    3、在使用某個對象當鎖時,改變了對象的引用,導致同步失效。
       這也是很常見的錯誤,類似下面的代碼:
    synchronized(array[0])
    {
       ......
       array[0]=new A();
       ......
    }
       同步塊使用array[0]作為鎖,然而在同步塊中卻改變了array[0]指向的引用。分析下這個場景,第一個線程獲取了array[0]的鎖,第二個線程因為無法獲取array[0]而等待,在改變了array[0]的引用后,第三個線程獲取了新的array[0]的鎖,第一和第三兩個線程持有的鎖是不一樣的,同步互斥的目的就完全沒有達到了。這樣代碼的修改,通常是將鎖聲明為final變量或者引入業務無關的鎖對象,保證在同步塊內不會被修改引用。

    4、沒有在循環中調用wait()。

        wait和notify用于實現條件變量,你可能知道需要在同步塊中調用wait和notify,為了保證條件的改變能做到原子性和可見性。常常看見很多代碼做到了同步,卻沒有在循環中調用wait,而是使用if甚至沒有條件判斷:
    synchronized(lock)
    {
      
    if(isEmpty()
         lock.wait();
       
    }
        對條件的判斷是使用if,這會造成什么問題呢?在判斷條件之前可能調用notify或者notifyAll,那么條件已經滿足,不會等待,這沒什么問題。在條件沒有滿足,調用了wait()方法,釋放lock鎖并進入等待休眠狀態。如果線程是在正常情況下,也就是條件被改變之后被喚醒,那么沒有任何問題,條件滿足繼續執行下面的邏輯操作。問題在于線程可能被意外甚至惡意喚醒,由于沒有再次進行條件判斷,在條件沒有被滿足的情況下,線程執行了后續的操作。意外喚醒的情況,可能是調用了notifyAll,可能是有人惡意喚醒,也可能是很少情況下的自動蘇醒(稱為“偽喚醒”)。因此為了防止這種條件沒有滿足就執行后續操作的情況,需要在被喚醒后再次判斷條件,如果條件不滿足,繼續進入等待狀態,條件滿足,才進行后續操作。
    synchronized(lock)
    {
       
    while(isEmpty()
         lock.wait();
       
    }
        沒有進行條件判斷就調用wait的情況更嚴重,因為在等待之前可能notify已經被調用,那么在調用了wait之后進入等待休眠狀態后就無法保證線程蘇醒過來。

    5、同步的范圍過小或者過大。

        同步的范圍過小,可能完全沒有達到同步的目的;同步的范圍過大,可能會影響性能。同步范圍過小的一個常見例子是誤認為兩個同步的方法一起調用也是將同步的,需要記住的是Atomic+Atomic!=Atomic。
       Map map=Collections.synchronizedMap(new HashMap());
      
    if(!map.containsKey("a")){
                map.put(
    "a", value);
       }
       這是一個很典型的錯誤,map是線程安全的,containskey和put方法也是線程安全的,然而兩個線程安全的方法被組合調用就不一定是線程安全的了。因為在containsKey和put之間,可能有其他線程搶先put進了a,那么就可能覆蓋了其他線程設置的值,導致值的丟失。解決這一問題的方法就是擴大同步范圍,因為對象鎖是可重入的,因此在線程安全方法之上再同步相同的鎖對象不會有問題。
           Map map = Collections.synchronizedMap(new HashMap());
          
    synchronized (map) {
                
    if (!map.containsKey("a")) {
                    map.put(
    "a", value);
                }
            }
       注意,加大鎖的范圍,也要保證使用的是同一個鎖,不然很可能造成死鎖。 Collections.synchronizedMap(new HashMap())使用的鎖是map本身,因此沒有問題。當然,上面的情況現在更推薦使用ConcurrentHashMap,它有putIfAbsent方法來達到同樣的目的并且滿足線程安全性。

        同步范圍過大的例子也很多,比如在同步塊中new大對象,或者調用費時的IO操作(操作數據庫,webservice等)。不得不調用費時操作的時候,一定要指定超時時間,例如通過URLConnection去invoke某個URL時就要設置connect timeout和read timeout,防止鎖被獨占不釋放。
    同步范圍過大的情況下,要在保證線程安全的前提下,將不必要同步的操作從同步塊中移出。

    6、正確使用volatile
        在jdk5修正了volatile的語義后,volatile作為一種輕量級的同步策略就得到了大量的使用。volatile的嚴格定義參考jvm spec,這里只從volatile能做什么,和不能用來做什么出發做個探討。

    volatile可以用來做什么?

    1)狀態標志,模擬控制機制。常見用途如控制線程是否停止:
    private volatile boolean stopped;
    public void close(){
       stopped
    =true;
    }

    public void run(){

       
    while(!stopped){
          
    //do something
       }
       
    }
      

        前提是do something中不會有阻塞調用之類。volatile保證stopped變量的可見性,run方法中讀取stopped變量總是main memory中的最新值。

    2)安全發布,如修復DLC問題,具體參考http://www.javaeye.com/topic/260515和http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
        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)不能用于做計數器
        public class CheesyCounter {
            
    private volatile int value;

            
    public int getValue() { return value; }

            
    public int increment() {
                
    return value++;
            }
        }

        因為value++其實是有三個操作組成的:讀取、修改、寫入,volatile不能保證這個序列是原子的。對value的修改操作依賴于value的最新值。解決這個問題的方法可以將increment方法同步,或者使用AtomicInteger原子類。

    2)與其他變量構成不變式
       一個典型的例子是定義一個數據范圍,需要保證約束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并不是線程安全方法。假設初始狀態為(0,5),同時調用setLower(4)和setUpper(3),兩個線程交叉進行,最后結果可能是(4,3),違反了約束條件。修改這個問題的辦法就是將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;
        }
    }

     

    評論

    # re: java多線程編程的常見陷阱  回復  更多評論   

    2009-04-27 12:04 by Icansoft
    看完后,覺得原來java多線程編程比想象中的還要復雜!

    # re: java多線程編程的常見陷阱  回復  更多評論   

    2009-04-27 17:38 by dennis
    @Icansoft
    嗯,其實我還想補充一點,不要把多線程當錘子
    主站蜘蛛池模板: XXX2高清在线观看免费视频| 18女人水真多免费高清毛片| a在线视频免费观看在线视频三区 a毛片成人免费全部播放 | 国产亚洲精品精品国产亚洲综合| 亚洲国产精品一区二区第一页免| 国产亚洲精品看片在线观看| 亚洲AV无码一区二区乱子伦| 久久综合图区亚洲综合图区 | 亚洲国产精品无码久久久久久曰 | 成年女人18级毛片毛片免费| 久久精品国产亚洲7777| 亚洲成A人片777777| 亚洲色偷偷综合亚洲AV伊人| 国产黄色一级毛片亚洲黄片大全| 亚洲乱码中文字幕手机在线| 久久久久无码专区亚洲av| 亚洲va久久久噜噜噜久久| 亚洲啪啪综合AV一区| 亚洲av无码一区二区三区乱子伦 | 久久亚洲国产成人亚| 亚洲av无码成人精品国产 | 国产精品视频免费一区二区| 亚洲精品老司机在线观看| 亚洲大香人伊一本线| 国产精品福利片免费看| 免费看少妇作爱视频| 亚洲最大黄色网址| 成全动漫视频在线观看免费高清版下载 | 国产成人精品日本亚洲直接| 日韩精品无码免费一区二区三区 | 亚洲无人区一区二区三区| 美国毛片亚洲社区在线观看| 午夜性色一区二区三区免费不卡视频 | 91高清免费国产自产| 日韩精品亚洲人成在线观看| 一区二区三区在线免费观看视频| 思思99re66在线精品免费观看| 亚洲一区中文字幕在线电影网| 亚洲免费精彩视频在线观看| 亚洲国产成人久久综合碰碰动漫3d | 亚洲乱码一区二区三区在线观看|