樂觀鎖與悲觀鎖
處理多線程并發(fā)訪問最常用的就是加鎖，鎖又分成樂觀鎖和悲觀鎖巢株。
悲觀鎖
在多線程訪問共享資源時槐瑞，同時只允許一個線程獨享此資源，其他線程都被悲觀鎖阻塞阁苞，只有當前擁有鎖的線程釋放鎖困檩，其他線程才能被喚起競爭這個資源，每個線程在獲取資源前都要悲觀的檢查該資源是否已經(jīng)被占用，所以悲觀鎖的開銷是巨大的阵漏，但安全性高，用synchronized關鍵字或者ReentrantLock都是悲觀鎖。
樂觀鎖
樂觀鎖假定在多線程修改共享資源時是有先后順序的怎爵，不會發(fā)生同時修改的沖突，所以操作都不進行加鎖，只是提交時檢查是否有沖突，有沖突則失敗拉讯，解決沖突的方法就是不斷自旋重試，直到成功鳖藕，所以樂觀鎖效率比悲觀鎖效率高魔慷，但也引入了自旋過多和ABA問題。
CAS
CAS全稱是compareAndSwap著恩，1.5中引入了java.util.concurrent包,其中樂觀鎖的實現(xiàn)就是基于CAS院尔，它是建立在“硬件指令集”上來控制原子性的，常見的CAS操作有：
public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x);
public final native boolean compareAndSwapLong(Object o, long offset, long expected, long x);
CAS的執(zhí)行步驟是將指定地址的值與期待的值比較喉誊，如果相等則修改成新值邀摆，如果不相等則放棄修改，在AtomicInteger中就使用了CAS伍茄，自增中如果修改失敗則自旋栋盹，重新獲取新值繼續(xù)自增
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
CAS帶來的問題
既然CAS能解決并發(fā)問題，那我們都使用CAS怎么樣敷矫？
CAS雖然是一種多線程的解決方案例获，但其實是需要根據(jù)業(yè)務場景區(qū)分的，CAS帶來的第一個問題就是ABA曹仗。
ABA問題
CAS比較的是該地址預期的值榨汤，如果在執(zhí)行CAS期間，有其他的線程修改了值并且最終此值與原值相同怎茫，CAS是會忽略修改歷史的收壕，比如：
CAS前記錄值為A，修改成B遭居，在修改前值A被修改成C又修改成A啼器，這時再執(zhí)行CAS就會通過，程序無法知道修改歷史俱萍，如果只是數(shù)值自增這樣的邏輯不用在乎ABA問題端壳，但如果業(yè)務邏輯需要關心值是否被修改過就需要解決ABA問題。
下面的例子存在ABA問題
Unsafe unsafe = getUnsafeInstance();
long offSet = 0;
try {
offSet = unsafe.objectFieldOffset(Integer.class.getDeclaredField("value"));
} catch (Exception ex) {
throw new Error(ex);
}
Integer value = 0;
long finalOffSet = offSet;
Thread thread1 = new Thread(()->{
boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 1);
boolean b1 = unsafe.compareAndSwapInt(value, finalOffSet, 1, 0);
System.out.println("result "+b +"-"+b1+" value "+ value);
});
Thread thread2 = new Thread(()->{
boolean b = unsafe.compareAndSwapInt(value, finalOffSet, 0, 3);
System.out.println("result "+b +" final value "+value);
});
thread1.start();
thread1.join();
thread2.start();
thread2.join();
取到Unsafe需要反射
public static Unsafe getUnsafeInstance() throws Exception{
Field unsafeStaticField =
Unsafe.class.getDeclaredField("theUnsafe");
unsafeStaticField.setAccessible(true);
return (Unsafe) unsafeStaticField.get(Unsafe.class);
}
輸出
result true-true value 0
result true final value 3
可以看出有ABA問題并且修改都成功了枪蘑。
解決這個問題可以引入版號损谦，java中可以使用AtomicStampedReference來解決ABA問題
線程1將值從0自增成1，stamp增加1岳颇，線程2自增2照捡，但stamp已經(jīng)改變，修改失敗
public static void main(String[] args) throws Exception {
AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference(0, 0);
Integer reference = atomicStampedReference.getReference();
int stamp = atomicStampedReference.getStamp();
Thread th1 = new Thread(() -> {
int stampT = stamp;
int newStamp = stampT + 1;
boolean b = atomicStampedReference.compareAndSet(reference, reference + 1, stampT, newStamp);
System.out.println("th1 result " + b);
});
Thread th2 = new Thread(() -> {
int stampT = stamp;
int newStamp = stampT + 1;
boolean b = atomicStampedReference.compareAndSet(reference, reference + 2, stampT, newStamp);
System.out.println("th2 result " + b);
});
th1.start();
th1.join();
th2.start();
th2.join();
}
輸出
th1 result true
th2 result false
自旋過多問題
如果并發(fā)的比較厲害话侧，修改失敗的概率就會增加栗精，失敗后的自旋相應的也會增多，會影響效率。
所以CAS適用于預期不太會發(fā)生沖突或者沖突不多的情況悲立，如果并發(fā)概率很大還是用悲觀鎖鹿寨。
