目錄
- 基本概念
- 實現(xiàn)方式(含實例)
- 優(yōu)缺點和適用場景
- 面試官追問：樂觀鎖加鎖嗎？
- 面試官追問：CAS有哪些缺點？
- 總結(jié)
一、基本概念
樂觀鎖和悲觀鎖是兩種思想，用于解決并發(fā)場景下的數(shù)據(jù)競爭問題。
樂觀鎖：樂觀鎖在操作數(shù)據(jù)時非常樂觀，認為別人不會同時修改數(shù)據(jù)。因此樂觀鎖不會上鎖，只是在執(zhí)行更新的時候判斷一下在此期間別人是否修改了數(shù)據(jù)：如果別人修改了數(shù)據(jù)則放棄操作，否則執(zhí)行操作。
悲觀鎖：悲觀鎖在操作數(shù)據(jù)時比較悲觀，認為別人會同時修改數(shù)據(jù)。因此操作數(shù)據(jù)時直接把數(shù)據(jù)鎖住，直到操作完成后才會釋放鎖；上鎖期間其他人不能修改數(shù)據(jù)。
二、實現(xiàn)方式(含實例)
在說明實現(xiàn)方式之前，需要明確：樂觀鎖和悲觀鎖是兩種思想，它們的使用是非常廣泛的，不局限于某種編程語言或數(shù)據(jù)庫。
悲觀鎖的實現(xiàn)方式是加鎖，加鎖既可以是對代碼塊加鎖（如Java的synchronized關(guān)鍵字），也可以是對數(shù)據(jù)加鎖（如MySQL中的排它鎖）。
樂觀鎖的實現(xiàn)方式主要有兩種：CAS機制和版本號機制
下面詳細介紹。
2.1、CAS（Compare And Swap）
??CAS操作包括了3個操作數(shù)：
??需要讀寫的內(nèi)存位置(V) 進行比較的預(yù)期值(A) 擬寫入的新值(B)
??CAS操作邏輯如下：
??如果內(nèi)存位置V的值等于預(yù)期的A值，則將該位置更新為新值B，否則不進行任何操作。
??許多CAS的操作是自旋的：如果操作不成功，會一直重試，直到操作成功為止。
??這里引出一個新的問題，既然CAS包含了Compare和Swap兩個操作，它又如何保證原子性呢？答案是：CAS是由CPU支持的原子操作，其原子性是在硬件層面進行保證的。
??下面以Java中的自增操作(i++)為例，看一下悲觀鎖和CAS分別是如何保證線程安全的。
在Java中自增操作不是原子操作，它實際上包含三個獨立的操作：
讀取i值； 加1； 將新值寫回i
因此，如果并發(fā)執(zhí)行自增操作，可能導(dǎo)致計算結(jié)果的不準確。在下面的代碼示例中：value1沒有進行任何線程安全方面的保護，value2使用了樂觀鎖(CAS)，value3使用了悲觀鎖(synchronized)。
運行程序，使用1000個線程同時對value1、value2和value3進行自增操作，可以發(fā)現(xiàn)：value2和value3的值總是等于1000，而value1的值常常小于1000。
public class Test {
//value1：線程不安全
private static int value1 = 0;
//value2：使用樂觀鎖
private static AtomicInteger value2 = new AtomicInteger(0);
//value3：使用悲觀鎖
private static int value3 = 0;
private static synchronized void increaseValue3(){
value3++;
}
public static void main(String[] args) throws Exception {
//開啟1000個線程，并執(zhí)行自增操作
for(int i = 0; i < 1000; ++i){
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
value1++;
value2.getAndIncrement();
increaseValue3();
}
}).start();
}
//打印結(jié)果
Thread.sleep(1000);
System.out.println("線程不安全：" + value1);
System.out.println("樂觀鎖(AtomicInteger)：" + value2);
System.out.println("悲觀鎖(synchronized)：" + value3);
}
}
[站外圖片上傳中...(image-f80179-1557143601103)]
??首先來介紹AtomicInteger。AtomicInteger是java.util.concurrent.atomic包提供的原子類，利用CPU提供的CAS操作來保證原子性；除了AtomicInteger外，還有AtomicBoolean、AtomicLong、AtomicReference等眾多原子類。
下面看一下AtomicInteger的源碼，了解下它的自增操作incrementAndGet()是如何實現(xiàn)的。
[站外圖片上傳中...(image-c4727f-1557143601103)]
??在jdk1.8中，直接使用了Unsafe的getAndAddInt方法，而在jdk1.7的Unsafe中，沒有此方法。基本可以斷定，Unsafe新增的方法是性能提升的關(guān)鍵。
Unsafe中封裝了一些類似指針的操作，因為指針的操作是不安全的。
Unsafe的源碼
[站外圖片上傳中...(image-ecc69b-1557143601103)]
??如圖中所示：
??自增操作是自旋CAS操作：在循環(huán)中進行compareAndSwapInt，如果執(zhí)行成功則退出，否則一直執(zhí)行。
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
??第一個參數(shù)var1為給定的對象，var2為對象內(nèi)的偏移量（其實就是一個字段到對象頭部的偏移量，通過這個偏移量可以快速定位字段），var4表示期望值，var5表示要設(shè)置的值。如果指定的字段的值等于var4，那么就會把它設(shè)置為var5.
??synchronized通過對代碼塊加鎖來保證線程安全：在同一時刻，只能有一個線程可以執(zhí)行代碼塊中的代碼。synchronized是一個重量級的操作，不僅是因為加鎖需要消耗額外的資源，還因為線程狀態(tài)的切換會涉及操作系統(tǒng)核心態(tài)和用戶態(tài)的轉(zhuǎn)換；不過隨著JVM對鎖進行的一系列優(yōu)化(如自旋鎖、輕量級鎖、鎖粗化等)，synchronized的性能表現(xiàn)已經(jīng)越來越好。
2.2、版本號機制(數(shù)據(jù)版本Version記錄機制)
??除了CAS，版本號機制也可以用來實現(xiàn)樂觀鎖。版本號機制的基本思路是：
讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提 交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應(yīng)記錄的當前版本信息進行比對，如果提交的數(shù)據(jù) 版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。
??需要注意的是，這里使用了版本號作為判斷數(shù)據(jù)變化的標記，實際上可以根據(jù)實際情況選用其他能夠標記數(shù)據(jù)版本的字段，如時間戳等。
假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個
version 字段，當前值為 1 ；而當前帳戶余額字段（ balance ）為 $100 。
1 操作員 A 此時將其讀出（ version=1 ），并從其帳戶余額中扣除 $50
（ $100-$50 ）。
2 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（ version=1 ），并
從其帳戶余額中扣除 $20 （ $100-$20 ）。
3 操作員 A 完成了修改工作，將數(shù)據(jù)版本號加一（ version=2 ），連同帳戶扣
除后余額（ balance=$50 ），提交至數(shù)據(jù)庫更新，此時由于提交數(shù)據(jù)版本大
于數(shù)據(jù)庫記錄當前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄 version 更新為 2 。
4 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數(shù)據(jù)庫提交數(shù)
據(jù)（ balance=$80 ），但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)，操作員 B 提交的
數(shù)據(jù)版本號為 2 ，數(shù)據(jù)庫記錄當前版本(再查一遍該記錄)也為 2 ，不滿足 “ 提交版本必須大于記
錄當前版本才能執(zhí)行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。
這樣，就避免了操作員 B 用基于 version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作
員 A 的操作結(jié)果的可能。
從上面的例子可以看出，樂觀鎖機制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷（操作員 A
和操作員 B 操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系
統(tǒng)整體性能表現(xiàn)。
三、優(yōu)缺點和適用場景
樂觀鎖和悲觀鎖并沒有優(yōu)劣之分，它們有各自適合的場景；下面從兩個方面進行說明。
3.1、功能限制
與悲觀鎖相比，樂觀鎖適用的場景受到了更多的限制，無論是CAS還是版本號機制。
例如，CAS只能保證單個變量操作的原子性，當涉及到多個變量時，CAS是無能為力的，而synchronized則可以通過對整個代碼塊加鎖來處理。再比如版本號機制，如果query的時候是針對表1，而update的時候是針對表2，也很難通過簡單的版本號來實現(xiàn)樂觀鎖。
3.2、競爭激烈程度
??如果悲觀鎖和樂觀鎖都可以使用，那么選擇就要考慮競爭的激烈程度：
當競爭不激烈 (出現(xiàn)并發(fā)沖突的概率小)時，樂觀鎖更有優(yōu)勢，因為悲觀鎖會鎖住代碼塊或數(shù)據(jù)，其他線程無法同時訪問，影響并發(fā)，而且加鎖和釋放鎖都需要消耗額外的資源。
當競爭激烈(出現(xiàn)并發(fā)沖突的概率大)時，悲觀鎖更有優(yōu)勢，因為樂觀鎖在執(zhí)行更新時頻繁失敗，需要不斷重試，浪費CPU資源。
四、追問：樂觀鎖加鎖嗎？
??1.樂觀鎖本身是不加鎖的，只是在更新時判斷一下數(shù)據(jù)是否被其他線程更新了；AtomicInteger便是一個例子。
??2.有時樂觀鎖可能與加鎖操作合作，例如，在前述updateCoins()的例子中，MySQL在執(zhí)行update時會加排它鎖。但這只是樂觀鎖與加鎖操作合作的例子，不能改變“樂觀鎖本身不加鎖”這一事實。
五、追問：CAS有哪些缺點？
下面是CAS一些不那么完美的地方：
5.1、ABA問題
假設(shè)有兩個線程——線程1和線程2，兩個線程按照順序進行以下操作： (1)線程1讀取內(nèi)存中數(shù)據(jù)為A； (2)線程2將該數(shù)據(jù)修改為B； (3)線程2將該數(shù)據(jù)修改為A； (4)線程1對數(shù)據(jù)進行CAS操作
??在第(4)步中，由于內(nèi)存中數(shù)據(jù)仍然為A，因此CAS操作成功，但實際上該數(shù)據(jù)已經(jīng)被線程2修改過了。這就是ABA問題。
??在AtomicInteger的例子中，ABA似乎沒有什么危害。但是在某些場景下，ABA卻會帶來隱患，例如棧頂問題：一個棧的棧頂經(jīng)過兩次(或多次)變化又恢復(fù)了原值，但是?？赡芤寻l(fā)生了變化。
??對于ABA問題，比較有效的方案是引入版本號，內(nèi)存中的值每發(fā)生一次變化，版本號都+1；在進行CAS操作時，不僅比較內(nèi)存中的值，也會比較版本號，只有當二者都沒有變化時，CAS才能執(zhí)行成功。Java中的AtomicStampedReference類便是使用版本號來解決ABA問題的。
5.2、高競爭下的開銷問題
??在并發(fā)沖突概率大的高競爭環(huán)境下，如果CAS一直失敗，會一直重試，CPU開銷較大。針對這個問題的一個思路是引入退出機制，如重試次數(shù)超過一定閾值后失敗退出。當然，更重要的是避免在高競爭環(huán)境下使用樂觀鎖。
5.3、功能限制
??CAS的功能是比較受限的，例如CAS只能保證單個變量（或者說單個內(nèi)存值）操作的原子性，這意味著：(1)原子性不一定能保證線程安全，例如在Java中需要與volatile配合來保證線程安全；(2)當涉及到多個變量(內(nèi)存值)時，CAS也無能為力。
??除此之外，CAS的實現(xiàn)需要硬件層面處理器的支持，在Java中普通用戶無法直接使用，只能借助atomic包下的原子類使用，靈活性受到限制。
