悲觀鎖
總是假設最壞的情況，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖
總是假設最好的情況，每次去拿數據的時候都認爲別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量。
悲觀鎖和樂觀鎖的區別
悲觀鎖和樂觀鎖是數據庫用來保證數據併發安全防止更新丟失的兩種方法，。悲觀鎖和樂觀鎖大部分場景下差異不大，一些獨特場景下有一些差別，一般我們可以從如下幾個方面來判斷：
-
1.響應速度：如果需要非常高的響應速度，建議採用樂觀鎖方案，成功就執行，不成功就失敗，不需要等待其他併發去釋放鎖
-
2.衝突頻率：如果衝突頻率非常高，建議採用悲觀鎖，保證成功率，如果衝突頻率大，樂觀鎖會需要多次重試才能成功，代價比較大
-
3.重試代價：如果重試代價大，建議採用悲觀鎖
兩種鎖的使用場景
從上面對兩種鎖的介紹，我們知道兩種鎖各有優缺點，不可認爲一種好於另一種，
- 像樂觀鎖適用於寫比較少的情況下（多讀場景），即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。
- 但如果是多寫的情況，一般會經常產生衝突，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適。