樂觀鎖 Optimistic Locking
樂觀鎖的概念
樂觀鎖機制采取了更加寬松的加鎖機制，樂觀鎖是相對悲觀鎖而言，也是為了避免資料庫幻讀、業務處理時間過長等原因引起資料處理錯誤的一種機制，但樂觀鎖不會刻意使用資料庫本身的鎖機制，而是依據資料本身來保證資料的正確性
CAS 樂觀鎖技術，當多個執行緒嘗試使用CAS同時更新同一個變數時，只有其中一個執行緒能更新變數的值，而其它執行緒都失敗，失敗的執行緒并不會被掛起，而是被告知這次競爭中失敗，并可以再次嘗試，
為什么要用樂觀鎖 ?
例如銀行轉賬流程
- B 的賬戶余額為 ￥300
- A 向 B 轉賬 ￥700
- 在 A 向 B 轉賬的同時 C 要 取走 B 的 ￥200（此時 B 的余額還是 ￥300）
- 這樣的流程走下來后 B 的余額會覆寫成 ￥100
設定樂觀鎖后
- C 的取款操作: 會判斷資料表當前的資料與操作時的資料是否相同(資料庫中B的余額 300 是否與操作時已經查出來 B 的余額是否一致)
- 如果資料相同則會更新資料，否則會認為 已經查出來 B 的資料為過期資料
使用樂觀鎖后卻產生了新的問題，就是ABA問題
- ABA問題: A 將 B 更新成 ￥1000 后 D 又將 B 更新為 ￥300，此時的 C 還認為 B 沒有被更新過，C 的操作還是會成功.但不代表這個程序就是沒有問題的
為了解決ABA問題,在資料庫表中增加version欄位
- 其目的是達到順序遞增,也就是修改這條資料后version會產生變化,這樣其他正在操作這條資料的執行緒都會執行失敗,因為他們都變成了過期資料
- 例子:
update t_user set sex = 1,version = version + 1 where user_id = 1 and version = 0;
這句SQL陳述句執行第一次會執行成功,執行第二次就會失敗,因為version已經發生改變
發展趨勢
在當前高并發,高可用等并發量較大情況下使用樂觀鎖基本成為第一選擇
樂觀鎖并未真正的加鎖，效率高，一旦鎖的力度掌握不好，更新失敗的概率就會比較高，也很容易發生業務失敗
本文就先說到這里，有問題歡迎留言討論
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/117754.html
標籤：Java