學習參考資料：周志明老師的著作《深入理解Java虛擬機（第3版）》

1.什么是執行緒安全

當多個執行緒同時訪問同一個物件時，如果不用考慮這些執行緒在運行時環境下的調度和交替執行，也不需要進行額外的同步，以及不需要在呼叫時進行任何其他的協調操作，呼叫這個物件的行為都可以獲得正確的結果，那就稱這個物件是執行緒安全的，

2.執行緒安全的實作方式

如何實作執行緒安全和代碼的撰寫具有很大的關系，但虛擬機提供的同步和鎖機制也至關重要

2.1互斥同步

同步是指當多個執行緒訪問共享資料時，保證在同一時刻只有一個執行緒在使用共享資料，

互斥是實作同步的一種手段，臨界區、互斥量和信號量都是常見的互斥實作方式，

因此在“互斥同步”這四個字里面，互斥是因，同步是果；互斥是方法，同步是目的，

• synchronized使用規則
  在Java里面，最基本的互斥同步手段是synchronized關鍵字，這是一種塊結構的同步語法，使用時為其制定一把鎖，執行緒只有拿到這把鎖才可以執行同步塊中的方法，如果并沒有指定鎖，那將根據 synchronized 修飾的方法型別（如實體方法或類方法），來決定是取代碼所在的物件實體還是取型別對應的 Class 物件來作為執行緒要持有的鎖，

• 重量級鎖
  從執行成本的角度看，synchronized 持有鎖是Java語言中一個重量級（Heavy-Weight）的操作，主流 Java 虛擬機實作中，Java 的執行緒是映射到作業系統的原生內核執行緒之上的，如果要阻塞或喚醒一條執行緒，則需要作業系統來幫忙完成，這就不可避免地陷入用戶態到核心態的轉換中，進行這種狀態轉換需要耗費很多的處理器時間，

• 正因為這樣Java虛擬機會對所進行優化，后面會有寫，

2.2非阻塞同步

1. 互斥同步中即便沒有執行緒之間競爭也還是會加鎖，這將會導致進行核心態轉換、維護鎖計數器和檢查是否有被阻塞的執行緒需要被喚醒等開銷，
2. 隨著硬體指令集的發展，我們有了另外一個選擇：基于沖突檢測的樂觀并發策略，通俗地說，就是先進行操作，如果沒有其他執行緒爭用共享資料，那操作就成功了；如果共享資料有爭用，產生了沖突，那就再采取其他的補償措施（最常見的補償措施就是不斷地重試，直到成功為止），這種樂觀的并發策略的許多實作都不需要把執行緒掛起，因此這種同步操作稱為非阻塞同步（Non-Blocking Synchronization），
3. 使用樂觀并發策略需要“硬體指令集的發展”才能實作，因為我們需要操作和沖突檢測這兩個步驟具備原子性，這兩個需要靠硬體來完成這件事情，硬體保證一個從語意上看起來需要多次操作的行為只通過一條處理器指令就能完成，這類指令常用的有：

• 測驗并設定（Test-and-Set），

• 獲取并增加（Fetch-and-Increment），

• 交換（Swap），

• 比較并交換（Compare-and-Swap，下文稱CAS），

• 加載鏈接/條件存盤（Load-Linked/Store-Conditional，下文稱LL/SC），

如下面這個例子：

/**
 * Atomic變數自增測驗
 */
public class AtomicTest {
    public static AtomicInteger race =new AtomicInteger(0);

    private static final int THREADS_COUNT=20;
    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < THREADS_COUNT; i++) {
            new Thread(){
                @Override
                public void run() {
                    for (int j = 0; j < 1000; j++) {
                        race.incrementAndGet();//自增
                    }
                }
            }.start();

        }
        Thread.sleep(2000);//等待所有執行緒執行完成

        System.out.println(race);//列印結果

    }
}

測驗結果為：20000

incrementAndGet()方法在一個無限回圈中，不斷嘗試將一個比當前值大1的新值賦給自己，如果失敗了，那說明在執行“獲取-設定”操作的時候值已經有了修改，于是再次回圈進行下一次操作，直到設定成功為止，

3.鎖優化

3.1自旋鎖與自適應自旋

在很多情況下，共享資料的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復執行緒并不值得，于是有了自旋鎖（為了讓執行緒等待，我們只需讓執行緒執行一個忙回圈也就是自旋）

• 自旋鎖的優點
  自旋鎖在JDK 1.6中默認開啟，自旋等待不能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了執行緒切換的開銷，但它是要占用處理器時間的，因此，如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之，如果鎖被占用的時間很長，那么自旋的執行緒只會白白消耗處理器資源，而不會做任何有用的作業，反而會帶來性能上的浪費，因此，自旋等待的時間必須要有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起執行緒了，自旋次數的默認值是10次，用戶可以使用引數-XX：PreBlockSpin來更改，

• 自旋鎖的優化（自適應自旋）
  在JDK 6 中對自旋鎖的優化，引入了自適應的自旋：自適應意味著自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定，如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，并且持有鎖的執行緒正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間，比如100個回圈，另外，如果對于某個鎖，自旋很少成功獲得過，那在以后要獲取這個鎖時將可能省略掉自旋程序，以避免浪費處理器資源，有了自適應自旋，隨著程式運行和性能監控資訊的不斷完善，虛擬機對程式鎖的狀況預測就會越來越準確，虛擬機就會變得越來越“聰明”了，

3.2鎖消除

鎖消除是指虛擬機即時編譯器在運行時，檢測到某段需要同步的代碼根本不可能存在競爭，就會將鎖進行消除，

• 鎖消除在什么情況下發生
  鎖消除的主要判定依據來源于逃逸分析的資料支持，如果判斷到一段代碼中，在堆上的所有資料都不會逃逸出去被其他執行緒訪問到，那就可以把它們當作堆疊上資料對待，認為它們是執行緒私有的，同步加鎖自然就無須再進行，
  比如下面這段例子：

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(); 
}

每個 StringBuffer.append()方法中都有一個同步塊，鎖就是 sb 物件，虛擬機觀察變數 sb，經過逃逸分析后會發現它的動態作用域被限制在 concatString() 方法內部，也就是 sb 的所有參考都永遠不會逃逸到concatString()方法之外，其他執行緒無法訪問到它，所以這里雖然有鎖，但是可以被安全地消除掉，在解釋執行時這里仍然會加鎖，但在經過服務端編譯器的即時編譯之后，這段代碼就會忽略所有的同步措施而直接執行，

3.3鎖粗化

原則上，我們在撰寫代碼的時候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享資料的實際作用域中才進行同步，這樣是為了使得需要同步的運算元量盡可能變少，即使存在鎖競爭，等待鎖的執行緒也能盡可能快地拿到鎖，

大多數情況下，上面的原則都是正確的，但是如果一系列的連續操作都對同一個物件反復加鎖和解鎖，甚至加鎖操作是出現在回圈體之中的，那即使沒有執行緒競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗，

如示例3.2中所示，連續的 append()方法就屬于這類情況，如果虛擬機探測到有這樣一串零碎的操作都對同一個物件加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部，以（示例2-2）為例，就是擴展到第一個 append()操作之前直至最后一個 append()操作之后，這樣只需要加鎖一次就可以了，

也就是，當虛擬機檢測到有一串連續且零碎的操作都使用同一個物件加鎖，虛擬機會擴大范圍只加一把鎖，

3.4輕量級鎖

• 輕量級鎖與重量級鎖對比
  自旋鎖的目標是降低執行緒切換的成本，如果鎖競爭激烈，我們不得不依賴于重量級鎖，讓競爭失敗的執行緒阻塞；如果完全沒有實際的鎖競爭，那么申請重量級鎖都是浪費的，輕量級鎖的目標是，減少無實際競爭情況下，使用重量級鎖產生的性能消耗，包括系統呼叫引起的內核態與用戶態切換、執行緒阻塞造成的執行緒切換等，

• 輕量級鎖何時發生
  顧名思義，輕量級鎖是相對于重量級鎖而言的，使用輕量級鎖時，不需要申請互斥量，僅僅將Mark Word中的部分位元組CAS更新指向執行緒堆疊中的Lock Record，如果更新成功，則輕量級鎖獲取成功，記錄鎖狀態為輕量級鎖；否則，說明已經有執行緒獲得了輕量級鎖，目前發生了鎖競爭（不適合繼續使用輕量級鎖），接下來膨脹為重量級鎖，

Mark Word是物件頭的一部分；每個執行緒都擁有自己的執行緒堆疊（虛擬機堆疊），記錄執行緒和函式呼叫的基本資訊，，

當然，由于輕量級鎖天然瞄準不存在鎖競爭的場景，如果存在鎖競爭但不激烈，仍然可以用自旋鎖優化，自旋失敗后再膨脹為重量級鎖，

3.5偏向鎖

在沒有實際競爭的情況下，還能夠針對部分場景繼續優化，如果不僅僅沒有實際競爭，自始至終，使用鎖的執行緒都只有一個，那么，維護輕量級鎖都是浪費的，偏向鎖的目標是，減少無競爭且只有一個執行緒使用鎖的情況下，使用輕量級鎖產生的性能消耗，輕量級鎖每次申請、釋放鎖都至少需要一次CAS，但偏向鎖只有初始化時需要一次CAS，

“偏向”的意思是，偏向鎖假定將來只有第一個申請鎖的執行緒會使用鎖（不會有任何執行緒再來申請鎖），因此，只需要在Mark Word中CAS記錄owner（本質上也是更新，但初始值為空），如果記錄成功，則偏向鎖獲取成功，記錄鎖狀態為偏向鎖，以后當前執行緒等于owner就可以零成本的直接獲得鎖；否則，說明有其他執行緒競爭，膨脹為輕量級鎖，

偏向鎖無法使用自旋鎖優化，因為一旦有其他執行緒申請鎖，就破壞了偏向鎖的假定，

后面還會陸陸續續更新這系列的讀書筆記，期待您的關注~~