怎麼定義樂觀鎖和悲觀鎖？
樂觀和悲觀是一種態度，展示了站在不同的角度看待問題的方式。樂觀的人認爲事情總會往好的方向發展，悲觀的人認爲事情總會往壞的方向發展，角度不同，採取的措施也不同。不能說誰好誰壞，各有優缺點。
悲觀鎖
共享的資源每次只能給一個線程使用，其他線程處於阻塞狀態，用完之後才釋放資源給其他線程使用。傳統的關係型數據庫裏就用了很多這種鎖機制，比如：行鎖、表鎖、讀鎖、寫鎖等，都是在操作之前先上鎖。Java中的synchronized和ReentrantLock等獨佔鎖就是悲觀鎖的思想實現。
想了解sychronzied和lock的區別，詳細見文章：https://mp.csdn.net/postedit
樂觀鎖
默認別人不會修改數據，所以不會上鎖，只有在做更新的時候纔會判斷更新期間有沒有其他人去更新這個數據，常用方法有版本號機制和CAS算法實現。樂觀鎖適用於多讀少寫的場景，可以提高吞吐量。像數據庫提供的wirte_condition機制，其實都是提供的樂觀鎖機制。在java.util.concurrent.atomic包下的原子變量類型就是使用了樂觀鎖的一種實現方式CAS實現的。
兩種鎖的使用場景
我們知道，這兩種鎖各有優缺點，像樂觀鎖適用於多讀少寫的場景，即衝突發生的情況比較少，省去了鎖的開銷，提高系統的吞吐量。但如果寫比較頻繁，一般會經常發生衝突（寫期間會有其他線程也做了寫操作），這就導致了應用會不斷的進行retry，這樣反倒降低了性能。所以，寫多的場景用悲觀鎖比較合適。
樂觀鎖常用的兩種實現方式
樂觀鎖一般採用版本號機制或CAS算法來實現
1.版本號機制
一般在表中加上一個數據的版本號version字段，代表數據被修改的次數，當數據被修改時，version值會直接加1。當線程A要更新數據庫數據時，在讀取數據的同時也會讀取version字段，在提交更新時，若之前讀取到的version值和爲之前讀取到的version值相等才更新，否則重試更新操作，直到更新成功。
場景舉例：
假設數據庫中帳戶信息表中有一個 version 字段，當前值爲 1 ；而當前帳戶餘額字段（ balance ）爲 ￥100 。
- 操作員 A 此時將其讀出（ version=1 ），並從其帳戶餘額中扣除 ￥50，待更新餘額：￥50=(100-50)。
- 在操作員 A 操作的過程中，操作員B 也讀入此用戶信息（ version=1 ），並從其帳戶餘額中扣除 20，待更餘額￥80=（100-20）。
- 操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除後餘額（ balance=￥50 ），提交至數據庫更新，此時由於提交數據版本大於數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新爲 2 。
- 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數據庫提交數據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操作員 B 提交的數據版本號爲 2 ，數據庫記錄當前版本也爲 2 ，不滿足 “ 提交版本必須大於記錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。
這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
2.CAS算法
CAS（compare and swap-比較與交換），是一種有名的無鎖算法。 即不使用鎖的情況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的情況下實現變量的同步，所以也叫非阻塞同步（Non-blocking-Sychronization）。CAS算法涉及三個操作數：
- 需要讀寫的內存值 V
- 進行比較的值 A
- 擬寫入的新值 B
當且僅當 V ==A時，CAS通過原子方式用新值B來更新V的值，否則不會執行任何操作（比較和替換是一個原子操作）。一般情況下是一個自旋操作，即不斷的重試。
樂觀鎖的缺點
ABA問題是樂觀鎖的一個常見問題
1 ABA 問題
- 初次讀取 V=A
- ......
- 更新檢查V=A
如果一個變量V初次讀取的時候是A值，並且在準備賦值的時候檢查到它仍然是A值，那我們就能說明它的值沒有被其他線程修改過了嗎？很明顯是不能的，因爲在這段時間它的值可能被改爲其他值，然後又改回A，那CAS操作就會誤認爲它從來沒有被修改過。這個問題被稱爲CAS操作的 “ABA”問題。
JDK 1.5 以後的 AtomicStampedReference 類就提供了此種能力，其中的 compareAndSet 方法就是首先檢查當前引用是否等於預期引用，並且當前標誌是否等於預期標誌，如果全部相等，則以原子方式將該引用和該標誌的值設置爲給定的更新值。
2 循環時間長開銷大
自旋CAS（也就是不成功就一直循環執行直到成功）如果長時間不成功，會給CPU帶來非常大的執行開銷。 如果JVM能支持處理器提供的pause指令那麼效率會有一定的提升，pause指令有兩個作用，第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序衝突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率。
3 只能保證一個共享變量的原子操作
CAS 只對單個共享變量有效，當操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5開始，提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象裏來進行 CAS 操作.所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合併成一個共享變量來操作。
CAS與synchronized的使用情景
簡單的來說CAS適用於多讀少寫的場景（多讀場景，衝突一般比較少），synchronized適用於寫比較多的情況下（多寫場景，衝突一般較多）
- 對於資源競爭較少（線程衝突較輕）的情況，synchronzed效率高於CAS。使用synchronized同步鎖進行線程阻塞和喚醒切換,以及用戶態和內核態間的切換操作額外浪費消耗cpu資源；而CAS基於硬件實現，不需要進入內核，不需要切換線程，操作自旋機率較少，因此可以獲得更高的性能。
- 對於資源競爭嚴重（線程衝突嚴重）的情況，CAS自旋的概率會比較大，從而浪費更多的CPU資源，效率低於synchronized。
補充： Java併發編程這個領域中synchronized關鍵字一直都是元老級的角色，很久之前很多人都會稱它爲 “重量級鎖” 。但是，在JavaSE 1.6之後進行了主要包括爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的 偏向鎖 和 輕量級鎖 以及其它各種優化之後變得在某些情況下並不是那麼重了。synchronized的底層實現主要依靠 Lock-Free 的隊列，基本思路是 自旋後阻塞，競爭切換後繼續競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。在線程衝突較少的情況下，可以獲得和CAS類似的性能；而線程衝突嚴重的情況下，性能遠高於CAS。