樂觀鎖和悲觀鎖

 

https://zhuanlan.zhihu.com/p/40211594

悲觀鎖（用前都上鎖）

老是假設最壞的狀況，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完後再把資源轉讓給其它線程）。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。Java中synchronized和ReentrantLock等獨佔鎖就是悲觀鎖思想的實現。

 

樂觀鎖（更新時判斷數據是否是新的）（cas 版本號 時間戳 mysql mvcc（行的建立時間，刪除時間））

老是假設最好的狀況，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號機制和CAS算法實現。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，像數據庫提供的相似於write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。

 

兩種鎖的使用場景

從上面對兩種鎖的介紹，咱們知道兩種鎖各有優缺點，不可認爲一種好於另外一種，像樂觀鎖適用於寫比較少的狀況下（多讀場景），即衝突真的不多發生的時候，這樣能夠省去了鎖的開銷，加大了系統的整個吞吐量。但若是是多寫的狀況，通常會常常產生衝突，這就會致使上層應用會不斷的進行retry，這樣反卻是下降了性能，因此通常多寫的場景下用悲觀鎖就比較合適。

CAS與synchronized的使用情景

簡單的來講CAS適用於寫比較少的狀況下（多讀場景，衝突通常較少），synchronized適用於寫比較多的狀況下（多寫場景，衝突通常較多）

1. 對於資源競爭較少（線程衝突較輕）的狀況，使用synchronized同步鎖進行線程阻塞和喚醒切換以及用戶態內核態間的切換操做額外浪費消耗cpu資源；而CAS基於硬件實現，不須要進入內核，不須要切換線程，操做自旋概率較少，所以能夠得到更高的性能。
2. 對於資源競爭嚴重（線程衝突嚴重）的狀況，CAS自旋的機率會比較大，從而浪費更多的CPU資源，效率低於synchronized。

 

cas 比較和替換是一個原子操做，通常失敗後就自旋操做，不斷重試

　　（aba問題）

　　（只能保證一個共享變量的原子操做）