Java併發編程學習：線程安全與鎖優化

本文參考《深入理解java虛擬機第二版》

一。什麼是線程安全？ 

  這裡我借《Java Concurrency In Practice》裡面的話：當多個線程訪問一個對象，如果不考慮這些線程在運行時環境下的調度和交替執行，也不需要額外的同步，或者調用方進行任何其他的協調操作，調用這個對象的行為都可以獲得正確的結果，那麼這個對象是線程安全的。

      我的理解：多線程訪問一個對象，任何情況下，都能保持正確行為，就是對象就是安全的。

   我們可以將Java語言中各種操作共用的數據分為以下5類：不可變、 絕對線程安全、 相對線程安全、 線程相容和線程對立。
1.不可變

   不可變（Immutable）的對象一定是線程安全的，無論是對象的方法實現還是方法的調用者，都不需要再採取任何的線程安全保障措施。
   Java語言中，如果共用數據是一個基本數據類型，那麼只要在定義時使用final關鍵字修飾它就可以保證它是不可變的。 如果共用數據是一個對象，那就需要保證對象的行為不會對其狀態產生任何影響才行，如果讀者還沒想明白這句話，不妨想一想java.lang.String類的對象，它是一個典型的不可變對象，我們調用它的substring（）、 replace（）和concat（）這些方法都不會影響它原來的值，只會返回一個新構造的字元串對象。保證對象行為不影響自己狀態的途徑有很多種，其中最簡單的就是把對象中帶有狀態的變數都聲明為final，這樣在構造函數結束之後，它就是不可變的
　　不可變的對象的，也就是被聲明成fianl的對象，只要被正確構建出來，在不發現this逃逸的情況下，其外部狀態永遠不會改變，永遠不會看到多個線程中處於不一致的狀態。也就是說所有對象的共用變數都聲明成final ，那麼就是安全的。

2.絕對線程安全

   絕對的線程安全完全滿足Brian Goetz給出的線程安全的定義，這個定義其實是很嚴格的，一個類要達到“不管運行時環境如何，調用者都不需要任何額外的同步措施”

   在Java API中標註自己是線程安全的類，大多數都不是絕對的線程安全。 
   如果說java.util.Vector是一個線程安全的容器，相信所有的Java程式員對此都不會有異議，因為它的add（）、 get（）和size（）這類方法都是被synchronized修飾的，儘管這樣效率很低，但確實是安全的。 但是，即使它所有的方法都被修飾成同步，也不意味著調用它的時候永遠都不再需要同步手段了。如果一個線程要查找i位置的變數，結果另一個線程把他刪除了，就會包異常。

拋出異常的原因：因為如果另一個線程恰好在錯誤的時間里刪除了一個元素，導致序號i 已經不再可用的話，再用i 訪問數組就會拋出一個 ArrayIndexOutOfBoundsException

如果要保證這段代碼能夠正確執行下去，修改後的代碼為

// 對線程安全的容器 Vector的測試(修改後的代碼)
public class ModifiedVectorTest {
    private static Vector<Integer> vector = new Vector<>(); 
    
    public static void main(String[] args) {
        while(true) {
            for (int i = 0; i < 100; i++) {
                vector.add(i);
            }
            
            Thread removeThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) { // 添加同步塊，this line
                        for (int i = 0; i < vector.size(); i++) {
                            vector.remove(i);
                        }
                    }
                }
            });
            
            Thread printThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) { // 添加同步塊，this line
                        for (int i = 0; i < vector.size(); i++) {
                            System.out.println(vector.get(i));
                        }
                    }
                }
            });
            
            removeThread.start();
            printThread.start();
            
            // 不要同時產生過多的線程，否則會導致os 假死
            while(Thread.activeCount() > 20);
        }
    }
}

3.相對線程安全

   相對的線程安全就是我們通常意義上所講的線程安全，它需要保證對這個對象單獨的操作是線程安全的，我們在調用的時候不需要做額外的保措施，但是對於一些特定順序的連續調用，就可能需要在調用端使用額外的同步手段來保證調用的正確性。 
   在Java語言中，大部分的線程安全類都屬於這種類型，例如Vector、 HashTable、Collections的synchronizedCollection（）方法包裝的集合等。

4.線程相容

   線程相容是指對象本身並不是線程安全的，但是可以通過在調用端正確地使用同步手段來保證對象在併發環境中可以安全地使用，我們平常說一個類不是線程安全的，絕大多數時候指的是這一種情況。 Java API中大部分的類都是屬於線程相容的，如與前面的Vector和HashTable相對應的集合類ArrayList和HashMap等。

5.線程對立

   線程對立是指無論調用端是否採取了同步措施，都無法在多線程環境中併發使用的代碼。 由於Java語言天生就具備多線程特性，線程對立這種排斥多線程的代碼是很少出現的，而且通常都是有害的，應當儘量避免。
   一個線程對立的例子是Thread類的suspend（）和resume（）方法，如果有兩個線程同時持有一個線程對象，一個嘗試去中斷線程，另一個嘗試去恢複線程，如果併發進行的話，無論調用時是否進行了同步，目標線程都是存在死鎖風險的，如果suspend（）中斷的線程就是即將要執行resume（）的那個線程，那就肯定要產生死鎖了。

1.6.3）關於synchronized 和 ReentrantLock 性能的分析：

對上圖的分析（Analysis）：

A1）多線程環境下 synchronized的吞吐量下降得非常嚴重，而 ReentrantLock 則能基本保持在同一個比較穩定的水平上；與其說ReentrantLock性能好，還不如說 synchronized還有非常大的優化餘地；

A2）虛擬機在未來的性能改進中肯定也會更加偏向於原生的 synchronized，所以還是提倡在 synchronized能實現需求的情況下，優先考慮使用 synchronized 來進行同步；

2.4）如何使用CAS 操作來避免阻塞同步，看個荔枝：（測試incrementAndGet 方法的原子性）

// Atomic 變數自增運算測試(incrementAndGet 方法的原子性)
public class AtomicTest {
    public static AtomicInteger race = new AtomicInteger(0);
    
    public static void increase() {
        // 輸出正確結果，一切都要歸功於 incrementAndGet 方法的原子性
        race.incrementAndGet();  
    }
    
    public static final int THREADS_COUNT = 20;
    
    public static void main(String[] args) throws Exception {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < threads.length; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int j = 0; j < 10000; j++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }
        
        while(Thread.activeCount() > 1) {
            Thread.yield();
        }
        
        System.out.println(race);
    }
    
    /**
     * incrementAndGet() 方法的JDK 源碼
     * Atomically increment by one the current value.
     * @return the updated value
     */
    public final int incrementAndGet() {
        for(;;) {
            int current = get();
            int next = current + 1;
            if(compareAndSet(current,next)) {
                return next;
            }
        }
    }
}

2.5）CAS操作（比較並交換操作）的ABA問題：如果一個變數V初次讀取的時候是A值，並且在準備賦值的時候檢查到它仍然是A值，那我們就說它的值沒有被其他線程改變過了嗎？ 如果在這段期間它的值曾經被改為了B，之後又改回了A，那CAS操作就會誤認為它從來沒有被改變過，這個漏洞稱為 CAS操作的 ABA問題；

2.6）解決方法：J.U.C 包為瞭解決這個問題，提供了一個帶有標記的原子引用類“AtomicStampedReference”，它可以通過控制變數值的version 來保證CAS的正確性。不過目前來說這個類比較雞肋， 大部分cases 下 ABA問題 不會影響程式併發的正確性，如果需要解決ABA問題，改用傳統的互斥同步可能會比原子類更高效；

public class LockEliminateTest {
    
    // raw code
    public String concatString(String s1, String s2, String s3) {
        return s1 + s2 + s3;
    }
    
    // javac 轉化後的字元串連接操作
    public String concatString(String s1, String s2, String s3) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }
}

 對以上代碼的分析（Analysis）：

A1）對於 javac 轉化後的字元串連接操作代碼： 使用了同步，因為StringBuffer.append() 方法中都有一個同步塊，鎖就是sb對象。虛擬機觀察變數sb，很快就會發現他的動態作用域被限制在 concatString() 方法內部；也就是所 sb 的所有引用都不會逃逸到方法之外；

A2）所以，雖然這裡有鎖，但是可以被安全地消除掉，在即時編譯之後，這段代碼就會忽略掉所有的同步而直接執行了；

3）以下麵的代碼為例，就是擴展到第一個 append() 操作前直到最後一個 append()操作之後，這樣只需要加鎖一次就可以了； 

// javac 轉化後的字元串連接操作
    public String concatString(String s1, String s2, String s3) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }