悲觀所與樂觀鎖

1、樂觀鎖
老是認爲不會產生併發問題，每次去取數據的時候總認爲不會有其餘線程對數據進行修改，所以不會上鎖，可是在更新時會判斷其餘線程在這以前有沒有對數據進行修改，通常會使用版本號機制或CAS操做實現。

version方式:
通常是在數據表中加上一個數據版本號version字段，表示數據被修改的次數，當數據被修改時，version值會加一。當線程A要更新數據值時，在讀取數據的同時也會讀取version值，在提交更新時，若剛纔讀取到的version值爲當前數據庫中的version值相等時才更新，不然重試更新操做，直到更新成功。

核心SQL代碼：

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

CAS操做方式:
即compare and swap 或者 compare and set，涉及到三個操做數，數據所在的內存值，預期值，新值。當須要更新時，判斷當前內存值與以前取到的值是否相等，若相等，則用新值更新，若失敗則重試，通常狀況下是一個自旋操做，即不斷的重試。

1、悲觀鎖
老是假設最壞的狀況，每次取數據時都認爲其餘線程會修改，因此都會加鎖（讀鎖、寫鎖、行鎖等），當其餘線程想要訪問數據時，都須要阻塞掛起。能夠依靠數據庫實現，如行鎖、讀鎖和寫鎖等，都是在操做以前加鎖，在Java中，synchronized的思想也是悲觀鎖。

這裏拋開數據庫來談樂觀鎖和悲觀鎖,扯上數據庫總會以爲和Java離得很遠.

悲觀鎖:一段執行邏輯加上悲觀鎖,不一樣線程同時執行時,只能有一個線程執行,其餘的線程在入口處等待,直到鎖被釋放.
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。

樂觀鎖:一段執行邏輯加上樂觀鎖,不一樣線程同時執行時,能夠同時進入執行,在最後更新數據的時候要檢查這些數據是否被其餘線程修改了(版本和執行初是否相同),沒有修改則進行更新,不然放棄本次操做.
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，像數據庫若是提供相似於write_condition機制的其實都是提供的樂觀鎖。

從解釋上能夠看出,悲觀鎖具備很強的獨佔性,也是最安全的.而樂觀鎖很開放,效率高,安全性比悲觀鎖低,由於在樂觀鎖檢查數據版本一致性時也可能被其餘線程修改數據.兩種鎖各有優缺點，不可認爲一種好於另外一種，像樂觀鎖適用於寫比較少的狀況下，即衝突真的不多發生的時候，這樣能夠省去了鎖的開銷，加大了系統的整個吞吐量。但若是常常產生衝突，上層應用會不斷的進行retry，這樣反卻是下降了性能，因此這種狀況下用悲觀鎖就比較合適。