程式安全
執行緒安全是程式開發中非常需要我們注意的一環，當程式存在并發的可能時，如果我們不做特殊的處理，很容易就出現資料不一致的情況，
通常情況下，我們可以用加鎖的方式來保證執行緒安全，通過對共享資源 (也就是要讀取的資料) 的加上"隔離的鎖"，使得多個執行緒執行的時候也不會互相影響，而悲觀鎖和樂觀鎖正是并發控制中較為常用的技術手段，
樂觀鎖和悲觀鎖
什么是悲觀鎖？什么是樂觀鎖？其實從字面上就可以區分出兩者的區別，通俗點說，
悲觀鎖
悲觀鎖就好像一個有迫害妄想癥的患者，總是假設最壞的情況，每次拿資料的時候都以為別人會修改，所以每次拿資料的時候都會上鎖，直到整個資料處理程序結束，其他的執行緒如果要拿資料就必須等當前的鎖被釋放后才能操作，
使用案例
悲觀鎖的使用場景并不少見，資料庫很多地方就用到了這種鎖機制，比如行鎖，表鎖，讀鎖，寫鎖等，都是在做操作之前先上鎖，悲觀鎖的實作往往依靠資料庫本身的鎖功能實作，Java程式中的Synchronized和ReentrantLock等實作的鎖也均為悲觀鎖，
在資料庫中，悲觀鎖的呼叫一般是在所要查詢的陳述句后面加上 for update，
select * from db_stock where goods_id = 1 for update
當有一個事務呼叫這條 sql 陳述句時，會對goods_id = 1 這條記錄加鎖，其他的事務如果也對這條記錄做 for update 的查詢的話，那就必須等到該事務執行完后才能查出結果，這種加鎖方式能對讀和寫做出排他的作用，保證了資料只能被當前事務修改，
當然，如果其他事務只是簡單的查詢而沒有用 for update的話，那么查詢還是不會受影響的，只是說更新時一樣要等待當前事務結束才行，
值得注意的是，MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交，就是說，如果我們不僅要讀，還要更新資料的話，需要手動控制事務的提交，比如像下面這樣：
set autocommit=0;
//開始事務
begin;
//查詢出商品id為1的庫存表資料
select * from db_stock where goods_id = 1 for update;
//減庫存
update db_stock set stock_num = stock_num - 1 where goods_id = 1 ;
//提交事務
commit;
雖然悲觀鎖能有效保證資料執行的順序性和一致性，但在高并發場景下并不適用，試想，如果一個事務用悲觀鎖對資料加鎖之后，其他事務將不能對加鎖的資料進行除了查詢以外的所有操作，如果該事務執行時間很長，那么其他事務將一直等待，這無疑會降低系統的吞吐量，
這種情況下，我們可以有更好的選擇，那就是樂觀鎖，
樂觀鎖
樂觀鎖的思想和悲觀鎖相反，總是假設最好的情況，認為別人都是友好的，所以每次獲取資料的時候不會上鎖，但更新資料那一刻會判斷資料是否被更新過了，如果資料的值跟自己預期一樣的話，那么就可以正常更新資料，
場景
這種思想應用到實際場景的話，可以用版本號機制和CAS演算法實作，
CAS
CAS是一種無鎖的思想，它假設執行緒對資源的訪問是沒有沖突的，同時所有的執行緒執行都不需要等待，可以持續執行，如果遇到沖突的話，就使用一種叫做CAS (比較交換) 的技術來鑒別執行緒沖突，如果檢測到沖突發生，就重試當前操作到沒有沖突為止，
原理
CAS的全稱是Compare-and-Swap，也就是比較并交換，它包含了三個引數：V，A，B，V表示要讀寫的記憶體位置，A表示舊的預期值，B表示新值
具體的機制是，當執行CAS指令的時候，只有當V的值等于預期值A時，才會把V的值改為B，如果V和A不同，有可能是其他的執行緒修改了，這個時候，執行CAS的執行緒就會不斷的回圈重試，直到能成功更新為止，
正是基于這樣的原理，CAS即時沒有使用鎖，也能發現其他執行緒對當前執行緒的干擾，從而進行及時的處理，
缺點
CAS算是比較高效的并發控制手段，不會阻塞其他執行緒，但是，這樣的更新方式是存在問題的，看流程就知道了，如果C的結果一直跟預期的結果不一樣的話，執行緒A就會一直不斷的回圈重試，重試次數太多的話對CPU也是一筆不小的開銷，
而且，CAS的操作范圍也比較局限，只能保證一個共享變數的原子操作，如果需要一段代碼塊的原子性的話，就只能通過Synchronized等工具來實作了，
除此之外，CAS機制最大的缺陷就是"ABA"問題，
ABA問題
前面說過，CAS判斷變數操作成功的條件是V的值和A是一致的，這個邏輯有個小小的缺陷，就是如果V的值一開始為A，在準備修改為新值前的期間曾經被改成了B，后來又被改回為A，經過兩次的執行緒修改物件的值還是舊值，那么CAS操作就會誤任務該變數從來沒被修改過，這就是CAS中的“ABA”問題，
看完流程圖相信也不用我說太多了吧，執行緒多發的情況下，這樣的問題是非常有可能發生的，那么如何避免ABA問題呢？
加標志位，例如搞個自增的欄位，沒操作一次就加一，或者是一個時間戳，每次更新比較時間戳的值，這也是資料庫版本號更新的思想（下面會說到）
在Java中，自JDK1.5以后就提供了這么一個并發工具類AtomicStampedReference，該工具內部維護了一個內部類，在原有基礎上維護了一個物件，及一個int型別的值（可以理解為版本號），在每次進行對比修改時，都會先判斷要修改的值，和記憶體中的值是否相同，以及版本號是否相同，如果全部相等，則以原子方式將該參考和該標志的值設定為給定的更新值，
private static class Pair<T> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
適用場景
CAS一般適用于讀多寫少的場景，因為這種情況執行緒的沖突不會太多，也只有執行緒沖突不嚴重的情況下，CAS的執行緒回圈次數才能有效的降低，性能也能更高，
版本號機制
版本號機制是資料庫更新操作里非常實用的技巧，其實原理很簡單，就是獲取資料的時候會拿一個能對應版本的欄位，然后更新的時候判斷這個欄位是否跟之前拿的值是否一致，一致的話證明資料沒有被別人更新過，這時就可以正常實作更新操作，
還是上面的那張表為例，我們加上一個版本號欄位version，然后每次更新資料的時候就把版本號加1，
select goods_id,stock_num,version from db_stock where goods_id = 1
update db_stock set stock_num = stock_num - 1,version = version + 1 where goods_id = 1 and version = #{version}
這樣的話，如果有兩個事務同時對goods_id = 1這條資料做更新操作的話，一定會有一個事務先執行完成，然后version欄位就加1，另一個事務更新的時候發現version已經不是之前獲取到的那個值了，就會重新執行查詢操作，從而保證了資料的一致性，
這種鎖的方式也不會影響吞吐量，畢竟大家都可以同時讀和寫，但高并發場景下，sql更新報錯的可能性會大大增加，這樣對業務處理似乎也不友好，
這種情況下，我們可以把鎖的粒度縮小，比如說減庫存的時候，我們可以這么處理：
update db_stock set stock_num = stock_num - 1 where goods_id = 1 and stock_num > 0
這樣一來，sql更新沖突的概率會大大降低，而且也不用去單獨維護類似version的欄位了，
最后
關于悲觀鎖和樂觀鎖的例子介紹就到這兒了，當然，本文也只是略微講解，更多的知識點還要靠大家研究，而且，除了這兩種鎖，并發控制中還有很多其他的控制手段，像什么Synchronized、ReentrantLock、公平鎖，非公平鎖之類的都是很常見的并發知識，不管是為了日常開發還是應付面試，掌握這些知識點還是很有必要的，而且，并發編程的知識思想是共通的，知道一塊知識點后很容易就能延伸去學習其他的知識點，
拿我自己來說，最近也在認真研究Java并發編程的一些知識點，也因為要寫樂觀鎖的緣故，順道復習了一下CAS和它的使用案例，從而也了解到了ReentrantLock底層其實就是通過CAS機制來實作鎖的，而且還了解了獨占鎖，共享鎖，可重入鎖等使用場景，由點到面，也讓我知識體系儲備更加的豐富，近期也有打算擼幾篇關于ReentrantLock知識的文章出來，歡迎大家多來踩踩！
作者：鄙人薛某，一個不拘于技術的互聯網人，技術三流，吹水一流，想看更多精彩文章可以關注我的公眾號哦~~~
原創不易，您的 【點贊】 將是我創作的最大動力，感謝各位的支持！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/27397.html
標籤：Java