悲觀鎖(Pessimistic Lock) 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。 樂觀鎖(Opt ...
悲觀鎖(Pessimistic Lock)
顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock)
顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。
優點與不足：
樂觀併發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此儘可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這麼做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了資料庫的某一行，經過修改以後寫回資料庫，這時就遇到了問題，可能會出現臟讀的情況。
下麵是一個簡單的示例：
一個典型的依賴資料庫的悲觀鎖調用：
select * from user where name=”mx” for update；這條 sql 語句鎖定了 user 表中所有符合檢索條件（ name=”mx” ）的記錄，本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
樂觀鎖的例子：
使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。
經典面試題～樂觀鎖和悲觀鎖
1.查詢出商品信息
select status,version from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status為2
update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};
即操作員A對數據商品狀態從1（未發貨）修改為2（已發貨），同時對版本號version +1，這樣操作員B假如在A之前就進入頁面，沒有刷新頁面之前顯示還是未發貨，當B修改狀態為2，版本號+1變成2提交時，不滿足 “ 提交版本必須大於記錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。
