樂觀鎖對應于生活中樂觀的人總是想著事情往好的方向發展，悲觀鎖對應于生活中悲觀的人總是想著事情往壞的方向發展。這兩種人各有優缺點，不能不以場景而定說一種人好于另外一種人。

悲觀鎖

總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉讓給其它線程）。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。Java中synchronized和ReentrantLock等獨占鎖就是悲觀鎖思想的實現。

樂觀鎖

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

兩種鎖的使用場景

從上面對兩種鎖的介紹，我們知道兩種鎖各有優缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下（多讀場景），即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果是多寫的情況，一般會經常產生沖突，這就會導致上層應用會不斷的進行retry，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適。

樂觀鎖常見的兩種實現方式 樂觀鎖一般會使用版本號機制或CAS算法實現。

版本號機制

一般是在數據表中加上一個數據版本號version字段，表示數據被修改的次數，當數據被修改時，version值會加一。當線程A要更新數據值時，在讀取數據的同時也會讀取version值，在提交更新時，若剛才讀取到的version值為當前數據庫中的version值相等時才更新，否則重試更新操作，直到更新成功。

舉一個簡單的例子： 假設數據庫中帳戶信息表中有一個 version 字段，當前值為 1 ；而當前帳戶余額字段（ balance ）為 $100 。

操作員 A 此時將其讀出（ version=1 ），并從其帳戶余額中扣除 50（100- 在操作員 A 操作的過程中，操作員B 也讀入此用戶信息（ version=1 ），并從其帳戶余額中扣除 20（100- 操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除后余額（ balance=$50 ），提交至數據庫更新，此時由于提交數據版本大于數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新為 2 。 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數據庫提交數據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，數據庫記錄當前版本也為 2 ，不滿足 “ 提交版本必須大于記錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基于 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。

CAS算法

即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的情況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的情況下實現變量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操作數

需要讀寫的內存值 V 進行比較的值 A 擬寫入的新值 B 當且僅當 V 的值等于 A時，CAS通過原子方式用新值B來更新V的值，否則不會執行任何操作（比較和替換是一個原子操作）。一般情況下是一個自旋操作，即不斷的重試。

以上就是Java中的悲觀鎖與樂觀鎖是什么的詳細內容，更多關于Java 悲觀鎖與樂觀鎖的資料請關注好吧啦網其它相關文章！