1. synchronized 關鍵字

1.1. 基本概念

（面試題：說一說自己對于 synchronized 關鍵字的了解）

synchronized關鍵字解決的是多個執行緒之間訪問資源的同步性，synchronized關鍵字可以保證被它修飾的方法或者代碼塊在任意時刻只能有一個執行緒執行，

另外，在 Java 早期版本中，synchronized屬于重量級鎖，效率低下，因為監視器鎖（monitor）是依賴于底層的作業系統的 Mutex Lock 來實作的，Java 的執行緒是映射到作業系統的原生執行緒之上的，如果要掛起或者喚醒一個執行緒，都需要作業系統幫忙完成，而作業系統實作執行緒之間的切換時需要從用戶態轉換到內核態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，這也是為什么早期的 synchronized 效率低的原因，慶幸的是在 Java 6 之后 Java 官方對從 JVM 層面對synchronized 較大優化，所以現在的 synchronized 鎖效率也優化得很不錯了，JDK1.6對鎖的實作引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷，

1.2. 使用 synchronized 關鍵字

（面試題：說說自己是怎么使用 synchronized 關鍵字，在專案中用到了嗎）

synchronized關鍵字最主要的三種使用方式：

• 修飾實體方法: 作用于當前物件實體加鎖，進入同步代碼前要獲得當前物件實體的鎖
• 修飾靜態方法: 也就是給當前類加鎖，會作用于類的所有物件實體，因為靜態成員不屬于任何一個實體物件，是類成員（ static 表明這是該類的一個靜態資源，不管new了多少個物件，只有一份），所以如果一個執行緒A呼叫一個實體物件的非靜態 synchronized 方法，而執行緒B需要呼叫這個實體物件所屬類的靜態 synchronized 方法，是允許的，不會發生互斥現象，因為訪問靜態 synchronized 方法占用的鎖是當前類的鎖，而訪問非靜態 synchronized 方法占用的鎖是當前實體物件鎖，
• 修飾代碼塊: 指定加鎖物件，對給定物件加鎖，進入同步代碼庫前要獲得給定物件的鎖，

總結： synchronized 關鍵字加到 static 靜態方法和 synchronized(class)代碼塊上都是是給 Class 類上鎖，synchronized 關鍵字加到實體方法上是給物件實體上鎖，盡量不要使用 synchronized(String a) 因為JVM中，字串常量池具有快取功能！

下面我以一個常見的面試題為例講解一下 synchronized 關鍵字的具體使用，

面試中面試官經常會說：“單例模式了解嗎？來給我手寫一下！給我解釋一下雙重檢驗鎖方式實作單例模式的原理唄！”

雙重校驗鎖實作物件單例（執行緒安全）

public class Singleton {
    private volatile static Singleton uniqueInstance;
    private Singleton() {
    }
    public static Singleton getUniqueInstance() {
       //先判斷物件是否已經實體過，沒有實體化過才進入加鎖代碼
        if (uniqueInstance == null) {
            //類物件加鎖
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

另外，需要注意 uniqueInstance 采用 volatile 關鍵字修飾也是很有必要，

uniqueInstance 采用 volatile 關鍵字修飾也是很有必要的， uniqueInstance = new Singleton(); 這段代碼其實是分為三步執行：

1. 為 uniqueInstance 分配記憶體空間
2. 初始化 uniqueInstance
3. 將 uniqueInstance 指向分配的記憶體地址

但是由于 JVM 具有指令重排的特性，執行順序有可能變成 1->3->2，指令重排在單執行緒環境下不會出現問題，但是在多執行緒環境下會導致一個執行緒獲得還沒有初始化的實體，例如，執行緒 T1 執行了 1 和 3，此時 T2 呼叫 getUniqueInstance() 后發現 uniqueInstance 不為空，因此回傳 uniqueInstance，但此時 uniqueInstance 還未被初始化，

使用 volatile 可以禁止 JVM 的指令重排，保證在多執行緒環境下也能正常運行，

private volatile static Singleton uniqueInstance;

1.3. 物件鎖和類鎖

類鎖就是全域鎖，當多個執行緒呼叫不同物件實體的同步方法時會產生互斥，具體實作方式如下：

• 修飾靜態方法
• 修飾代碼塊，synchronized中的鎖物件是類

synchronized(Test.class){
    //哪個執行緒搶到了類鎖，哪個執行緒就執行，這里面的內容就只由這個執行緒執行
}

物件鎖就是實體鎖，當多個執行緒呼叫同一個物件實體的同步方法時會產生互斥，具體實作方式如下：

• 修飾普通方法
• 修飾代碼塊，synchronized中的鎖物件是普通物件實體

public class Test{
    Object lock = new Object();
    public void method(){
        synchronized(lock){
        }
    }
}

此時并沒有達到執行緒互斥的目的，實際上并不是鎖沒有生效，問題的根源在于synchronized(lock)中鎖物件lock的作用范圍過小，不同的Test實體會有不同的lock鎖物件，由于不滿足“如果要達到多個執行緒互斥，那么多個執行緒必須競爭同一個物件鎖”的條件，而沒有形成競爭，所以不會實作互斥的效果，如果想要讓上述程式達到同步的目的，那么我們可以對lock鎖物件添加static關鍵字，

static Object lock = new Object();

例如在實戰專案中，用到的一個插入資料之前先判斷該用戶是否含有這節課，通過課程名和用戶ID來判斷，此時多執行緒獲取用戶資料的場景下，由于無法保證整型變數n的原子性，有可能導致執行緒A將queryMapper的結果放入查詢后回傳的數量是0，此時if(n==1)判斷成功，進入后執行緒B插入的是物件和queryMapper中判斷重復的物件不是同一個，造成插入資料的重復，所以要確保有靜態修飾的鎖物件，使進入的執行緒只能有一個，執行結束后釋放鎖才讓另一個執行緒執行，

synchronized (insertLock) {
    int n = gradeMapper.selectCount(queryWrapper);
    if (n == 0) {
        int insert = gradeMapper.insert(gradeObj);
        if (insert == 1) {
            System.out.println(userOpenid + "---" + "插入成績成功---" + subject);
        }else {
            log.info(userOpenid +  "未能成功插入成績");
        }
    }
}

1.4. synchronized 關鍵字的底層原理

首先演示一下對synchronized同步鎖的實作猜想

如果synchronized同步鎖想要實作多執行緒訪問的互斥性，就必須保證多個執行緒競爭同一個資源，所以要實作鎖互斥就必須滿足以下兩個條件：

• 必須競爭同一個共享資源，
• 需要有一個標記來識別當前鎖的狀態是空閑還是繁忙，

第一個條件通過lock鎖物件來實作即可；第二個條件需要有一個地方來存盤搶占鎖的標記，否則當其他執行緒來搶占資源時，不知道當前是應該正常執行還是應該排隊，實際上，這個鎖標記是存盤在物件頭中的，

在堆記憶體中，Java物件存盤結構可分為三個部分：物件頭、實體資料、對齊填充，

Java中物件頭有三個部分組成：Mark World、Klass Pointer、Length，

Mark World記錄了與物件和鎖相關的資訊，當這個物件作為鎖物件來實作synchronized的同步操作時，鎖標記和相關資訊都是存盤在Mark World中的，

在Mark World中，鎖的型別有偏向鎖、輕量級鎖、重量級鎖，其實，早在jdk1.6之前，synchronized只提供了重量級鎖的機制，重量級鎖的本質就是我們前面對于鎖的認知，也就是沒有獲得鎖的執行緒會通過park方法阻塞，接著被獲得鎖的執行緒喚醒后再次搶占鎖，直到搶占成功，

重量級鎖依賴于底層作業系統的Mutex Lock來實作，而使用Mutex Lock需要把當前執行緒掛起，并**從用戶態切換到內核態（從程式層面切換到CPU層面）**來執行，這種切換帶來的性能開銷是非常大的，因此如何在性能和執行緒安全性之間做好平衡，就是一個值得深討的話題了，

在jdk1.6之后，synchronized做了很多優化，其中針對鎖的型別增加了偏向鎖和輕量級鎖，這兩種鎖的核心設計理念就是如何讓執行緒在不阻塞的情況下達到執行緒安全的目的，

synchronized 關鍵字底層原理屬于 JVM 層面，

① synchronized 同步陳述句塊的情況

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("synchronized 代碼塊");
        }
    }
}

通過 JDK 自帶的 javap 命令查看 SynchronizedDemo 類的相關位元組碼資訊：首先切換到類的對應目錄執行 javac SynchronizedDemo.java 命令生成編譯后的 .class 檔案，然后執行javap -c -s -v -l SynchronizedDemo.class，

從上面我們可以看出：

synchronized 同步陳述句塊的實作使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代碼塊的開始位置，monitorexit 指令則指明同步代碼塊的結束位置， 當執行 monitorenter 指令時，執行緒試圖獲取鎖也就是獲取 monitor（monitor物件存在于每個Java物件的物件頭中，synchronized 鎖便是通過這種方式獲取鎖的，也是為什么Java中任意物件可以作為鎖的原因）的持有權，當計數器為0則可以成功獲取，獲取后將鎖計數器設為1也就是加1，相應的在執行 monitorexit 指令后，將鎖計數器設為0，表明鎖被釋放，如果獲取物件鎖失敗，那當前執行緒就要阻塞等待，直到鎖被另外一個執行緒釋放為止，

② synchronized 修飾方法的的情況

public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}

synchronized關鍵字原理

synchronized 修飾的方法并沒有 monitorenter 指令和 monitorexit 指令，取得代之的確實是 ACC_SYNCHRONIZED 標識，該標識指明了該方法是一個同步方法，JVM 通過該 ACC_SYNCHRONIZED 訪問標志來辨別一個方法是否宣告為同步方法，從而執行相應的同步呼叫，

1.5. synchronized的鎖型別

JDK1.6 對鎖的實作引入了大量的優化，如偏向鎖、輕量級鎖、自旋鎖、適應性自旋鎖、鎖消除、鎖粗化等技術來減少鎖操作的開銷，（面試題：說說 JDK1.6 之后的synchronized 關鍵字底層做了哪些優化，可以詳細介紹一下這些優化嗎）

鎖主要存在四種狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨著競爭的激烈而逐漸升級，注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率，

1.5.1. 偏向鎖

偏向鎖的作用是，執行緒在沒有執行緒競爭的情況下去訪問synchronized同步代碼塊時，會嘗試先通過偏向鎖來搶占訪問資格，這個搶占程序是基于CAS來完成的，如果搶占鎖成功，則直接修改物件頭中的鎖標記，這個鎖標記就方便當該執行緒再次訪問這個同步方法的時候只需進行判斷后決定是否進入執行即可，其實作原理如下：

此時你可能會疑惑：既然是執行緒在沒有執行緒競爭的情況下去訪問synchronized同步代碼塊，既然沒有執行緒競爭，那為什么還需要設定鎖呢，實際上對程式開發來說，加鎖是為了防范執行緒安全性的風險，但是是否有執行緒競爭并不由我們來控制，而是由應用場景來決定的，同時，這也是synchronized鎖升級機制的一個基本的初始部分，

1.5.2. 輕量級鎖

在執行緒沒有競爭時，使用偏向鎖能夠在不影響性能的前提下獲得鎖資源，但是同一時刻只允許一個執行緒獲得鎖資源，如果突然有多個執行緒來訪問同步方法，那么沒有搶占到鎖資源的執行緒要怎么辦呢？很顯然偏向鎖解決不了這個問題，

正常情況下，沒有搶占到鎖的執行緒肯定要阻塞等待被喚醒，也就是說按照重量級鎖的邏輯來實作，但是在此之前，有沒有更好的平衡方案呢？于是就有了輕量級鎖的設計，

所謂的輕量級鎖，就是沒有搶占到鎖的執行緒，進行一定次數的重試（自旋），比如執行緒第1次沒搶到鎖則重試幾次，如果在重試的程序中搶占到了鎖，那么這個執行緒就不需要阻塞，這種實作方式我們稱為自旋鎖，具體的實作流程如下：

當然，執行緒通過重試來搶占鎖的方式是有代價的，因為執行緒如果不斷自旋重試，那么CPU 會一直處于運行狀態，如果持有鎖的執行緒占有鎖的時間比較短，那么自旋等待的實作帶來性能的提升會比較明顯，反之，如果持有鎖的執行緒占用鎖資源的時間比較長，那么自旋的執行緒就會浪費 CPU 資源，所以執行緒重試搶占鎖的次數必須要有一個限制，

在JDK 1.6中默認的自旋次數是10次，我們可以通過-XX:PreBlockSpin 引數來調整自旋次數，同時開發者在JDK 1.6 中還對自旋鎖做了優化，引入了自適應自旋鎖，自適應自旋鎖的自旋次數不是固定的，而是根據前一次在同一個鎖上的自旋次數及鎖持有者的狀態來決定的，如果在同一個鎖物件上，通過自旋等待成功獲得過鎖，并且持有鎖的執行緒正在運行中，那么JVM 會認為此次自旋也有很大的機會獲得鎖，因此會將這個執行緒的自旋時間相對延長，反之，如果在一個鎖物件中，通過自旋鎖獲得鎖很少成功，那么JVM會縮短自旋次數，

1.5.3. 重量級鎖

如果沒有強占到鎖資源的縣城通過一定次數的自旋后，發現仍然沒有獲得鎖，就只能阻塞等待了，所以最會升級到重量級鎖，通過系統層面的互斥量來搶占鎖的資源，重量級鎖的實作原理如下：

在整體來看，如果在偏向鎖、輕量級鎖這些型別中無法讓執行緒獲得鎖資源，那么這些沒獲得鎖的執行緒的最終的結果仍然是阻塞等待，直到獲得鎖的執行緒釋放鎖之后才能被喚醒，而在整個優化程序中，我們通過樂觀鎖的機制來保證執行緒的安全性，

synchronized同步鎖最終的底層加鎖機制是JVM層面根據執行緒的競爭情況逐步升級來實作的，從而達到同步鎖性能和安全性平衡的目的，而這個程序并不需要開發者干預，

1.6. CAS機制的實作原理分析

在synchronized中很多地方都用到了CAS機制，它的叫法有很多，比如CompareAndSwap等，它是一個能夠進行比較和替換的方法，這個方法能夠在多執行緒環境下保證對一個共享變數進行修改時的原子性不變，CAS的作業原理如下：

Java中的AtomicInteger常用于多執行緒執行的場景中，例如當多個執行緒操作海量用戶資料的時候，利用AtomicInteger userCount = new AtomicInteger();在execute中即可實作對用戶數量的計數，而不產生執行緒安全問題，這個程序正是利用了CAS機制來保證其原子性，

1.7. 鎖升級的實作流程

至于鎖升級的程序中，偏向鎖、輕量級鎖、重量級鎖的實作原理，包含其獲取和釋放程序是一個比較復雜的流程，見《Java并發編程——深度決議與實戰》P77，

不管是執行緒級別的死鎖，還是資料庫級別的死鎖，只能通過人工干預去解快，所以抵1發仕寫程式的時候提前預防死鎖的問題，導致死鎖的條件有四個，這四個條件同時滿足就會產生死鎖，互斥條件，共享資源又和￥只能被一個執行緒占用，請求和保持條件，執行緒T1已經取得共享資源叉，在等待共享資源Y的時候，不釋放共享
資源X，不可搶占條件，其他執行緒不能強行搶占執行緒 T1 古有的資源，回圈等待條件，執行緒 T1 等待執行緒 T2 占有的資源，執行緒 T2 等待執行緒 T1 占有的資源，即回圈等待，

1.8. synchronized使用不當帶來的死鎖問題

簡單來說就是兩個或者兩個以上的執行緒在執行的程序中，由于爭奪同一個共享資源造成的相互等待的現象，在沒有外部干預的情況下，這些執行緒將會無法往下執行，這些一直處于相互等待資源的執行緒就被稱為死鎖執行緒，

不管是執行緒級別的死鎖，還是資料庫級別的死鎖，只能通過人工干預去解快，所以我們要在寫程式的時候提前預防死鎖的問題，導致死鎖的條件有四個，這四個條件同時滿足就會產生死鎖，

• 互斥條件，共享資源X 和 Y只能被一個執行緒占用，
• 請求和保持條件，執行緒T1已經取得共享資源叉，在等待共享資源Y的時候，不釋放共享資源X，
• 不可搶占條件，其他執行緒不能強行搶占執行緒 T1 占有的資源，
• 回圈等待條件，執行緒 T1 等待執行緒 T2 占有的資源，執行緒 T2 等待執行緒 T1 占有的資源，即回圈等待，

如何解決

按照前面說的四個死鎖的發生條件，我們只需要破壞其中任意一個，就可以避免死鎖的產生，其中，互斥條件我們不可以破壞，因為這是互斥鎖的基本約束，其他三個條件都可以破壞，

• 對于請求和保持條件，我們可以一次性申請所有的資源，這樣就不存在等待了，
• 對于不可搶占條件，當占用部分資源的執行緒進一步申請其他資源時，如果申請不到，則可以主動釋放其占有的資源，這樣不可搶占條件就被破壞掉了，
• 對于回圈等待條件，可以通過按序申請資源來預防，所謂按序申請，是指資源是有線性順序的，申請的時候可以先申請資源序號小的，再申請資源序號大的，這樣線性化后自然就不存在回圈了，

具體代碼示例見《Java并發編程——深度決議與實戰》P92，

1.9. synchronized和ReentrantLock 的區別

① 兩者都是可重入鎖

兩者都是可重入鎖，“可重入鎖”概念是：自己可以再次獲取自己的內部鎖，比如一個執行緒獲得了某個物件的鎖，此時這個物件鎖還沒有釋放，當其再次想要獲取這個物件的鎖的時候還是可以獲取的，如果不可鎖重入的話，就會造成死鎖，同一個執行緒每次獲取鎖，鎖的計數器都自增1，所以要等到鎖的計數器下降為0時才能釋放鎖，

② synchronized 依賴于 JVM 而 ReentrantLock 依賴于 API

synchronized 是依賴于 JVM 實作的，前面我們也講到了 虛擬機團隊在 JDK1.6 為 synchronized 關鍵字進行了很多優化，但是這些優化都是在虛擬機層面實作的，并沒有直接暴露給我們，ReentrantLock 是 JDK 層面實作的（也就是 API 層面，需要 lock() 和 unlock() 方法配合 try/finally 陳述句塊來完成），所以我們可以通過查看它的源代碼，來看它是如何實作的，

③ ReentrantLock 比 synchronized 增加了一些高級功能

相比synchronized，ReentrantLock增加了一些高級功能，主要來說主要有三點：①等待可中斷；②可實作公平鎖；③可實作選擇性通知（鎖可以系結多個條件）

• ReentrantLock提供了一種能夠 中斷等待鎖的執行緒 的機制，通過lock.lockInterruptibly()來實作這個機制，也就是說正在等待的執行緒可以選擇放棄等待，改為處理其他事情，
• ReentrantLock可以指定是公平鎖還是非公平鎖，而synchronized只能是非公平鎖，所謂的公平鎖就是先等待的執行緒先獲得鎖， ReentrantLock默認情況是非公平的，可以通過 ReentrantLock類的ReentrantLock(boolean fair)構造方法來制定是否是公平的，
• synchronized關鍵字與wait()和notify()/notifyAll()方法相結合可以實作等待/通知機制，ReentrantLock類當然也可以實作，但是需要借助于Condition介面與newCondition() 方法，Condition是JDK1.5之后才有的，它具有很好的靈活性，比如可以實作多路通知功能，也就是在一個Lock物件中可以創建多個Condition實體（即物件監視器），執行緒物件可以注冊在指定的Condition中，從而可以有選擇性的進行執行緒通知，在調度執行緒上更加靈活， 在使用notify()/notifyAll()方法進行通知時，被通知的執行緒是由 JVM 選擇的，用ReentrantLock類結合Condition實體可以實作“選擇性通知” ，這個功能非常重要，而且是Condition介面默認提供的，而synchronized關鍵字就相當于整個Lock物件中只有一個Condition實體，所有的執行緒都注冊在它一個身上，如果執行notifyAll()方法的話就會通知所有處于等待狀態的執行緒這樣會造成很大的效率問題，而Condition實體的signalAll()方法 只會喚醒注冊在該Condition實體中的所有等待執行緒，

如果你想使用上述功能，那么選擇ReentrantLock是一個不錯的選擇，

④ 性能已不是選擇標準

2. volatile關鍵字

2.1. Java記憶體模型

在 JDK1.2 之前，Java的記憶體模型實作總是從主存（即共享記憶體）讀取變數，是不需要進行特別的注意的，而在當前的 Java 記憶體模型下，執行緒可以把變數保存本地記憶體（比如機器的暫存器）中，而不是直接在主存中進行讀寫，這就可能造成一個執行緒在主存中修改了一個變數的值，而另外一個執行緒還繼續使用它在暫存器中的變數值的拷貝，造成資料的不一致，

要解決這個問題，就需要把變數宣告為volatile，這就指示 JVM，這個變數是不穩定的，每次使用它都到主存中進行讀取，

例如在單例模式的實作中，使用 volatile 可以禁止 JVM 的指令重排，保證在多執行緒環境下也能正常運行，

public class Singleton {
    private volatile static Singleton uniqueInstance;
    private Singleton() {
    }
    public static Singleton getUniqueInstance() {
       //先判斷物件是否已經實體過，沒有實體化過才進入加鎖代碼
        if (uniqueInstance == null) {
            //類物件加鎖
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

什么是可見性？

如果一個執行緒對一個共享變數進行了修改，而其他執行緒不能及時地讀取修改之后的值，那么我們認為在多執行緒環境下該共享變數存在可見性問題，舉個具體例子如下：

public class VolatileExample{
    //public static boolean stop = false;
    public volatile static boolean stop = false;  //1秒后執行緒能正常結束
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(()->{
            int i = 0;
            while(!stop){
                i++;
            }
        });
        t1.start();
        System.out.printin("begin start thread");
        Thread.sleep(1000) ;
        stop = true;
    }
}

代碼的邏輯很簡單，首先t1通過stop變數來判斷是否一直執行while中的內容，而主執行緒在sleep一秒鐘后就將stop設定為了true，但此時t1執行緒卻不會停止執行，這是因為執行緒 t1 可以把變數保存在本地記憶體（比如機器的暫存器）中，而不是直接在主存中進行讀寫，這就可能造成一個執行緒（例如本代碼的主執行緒）在主存中修改了一個變數（stop）的值，而另外一個執行緒（執行緒t1）還繼續使用它在暫存器中的變數值的拷貝，造成資料的不一致，所以此處就要添加volatile關鍵字，去指示 JVM，這個變數是不穩定的，每次使用它都到主存中進行讀取，

由此可見，volatile可以禁止編譯器的優化，在多處理器環境下保證共享變數的可見性，

2.2. synchronized 關鍵字和 volatile 關鍵字的區別

synchronized關鍵字和volatile關鍵字比較

• volatile關鍵字是執行緒同步的輕量級實作，所以volatile性能肯定比synchronized關鍵字要好，但是volatile關鍵字只能用于變數而synchronized關鍵字可以修飾方法以及代碼塊，synchronized關鍵字在JavaSE1.6之后進行了主要包括為了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖以及其它各種優化之后執行效率有了顯著提升，實際開發中使用 synchronized 關鍵字的場景還是更多一些，
• 多執行緒訪問volatile關鍵字不會發生阻塞，而synchronized關鍵字可能會發生阻塞
• volatile關鍵字能保證資料的可見性，但不能保證資料的原子性，synchronized關鍵字兩者都能保證，
• volatile關鍵字主要用于解決變數在多個執行緒之間的可見性，而 synchronized關鍵字解決的是多個執行緒之間訪問資源的同步性，