> # 樂觀鎖和悲觀鎖 > ### 悲觀鎖 - `悲觀鎖（Pessimistic Lock）`，顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖、表鎖、讀鎖、寫鎖等，都是在做操作之前先上鎖。 - 假設最壞的情況， 每次讀取數據的時候都認為別人會修改，所以每次讀取數據都上鎖 - MySQL的`FOR SHARE`和`FOR UPDATE`是兩種不同的行級鎖模式，它們用于控制并發訪問數據時的鎖定行為。 - `FOR SHARE`是一種共享鎖模式，允許多個事務同時獲得共享鎖以讀取數據， - `FOR UPDATE`是一種排他鎖模式 - LOCK IN SHARE MODE` 和 `FOR SHARE` 是 MySQL 中兩種用于行級鎖的方式 --- - 讀寫（共享鎖) : select * from key_table lock in share mode (多個查詢間不阻塞, 插入、更新 阻塞) - 寫鎖（排它鎖) : select * from key_table for update (查詢、插入、更新 都阻塞) --- - SELECT *,SLEEP(2) FROM `data` lock in share mode; - 這時候去查詢表不會阻塞 - SELECT *,SLEEP(2) FROM `data` for update; - 這時候去查詢表會阻塞 > ### 樂觀鎖（**樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量**） - `樂觀鎖（Optimistic Lock）`，顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制實現。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量。 - 假設最好的情況， 每次讀取數據的時候都認為別人不會修改，不上鎖， 只是在更新數據的時候檢查有沒有其他人也在這個時間段更新數據 - 實現方式1 - 往數據庫表添加一個版本號字段， 每次修改前查詢當前版本號， 修改時版本號加1 - 1.select id,key1, key2, key3, version from table - 2.update table set key1=5,version=version+1 where id={上查詢結果的id} and version={上查詢結果的version} - 實現方式2 : 自旋鎖 - CAS算法 (缺點:1.存在ABA問題 2.循環時間長、開銷很大 3.只能保證一個共享變量的原子操作, ) - MySQL服務運行中, 修改表結構, 那些需要加鎖, 哪些不需要 - DML (數據操縱語言，Data Manipulation Language ):增刪查改 - DDL(數據定義語言,Data Definition Language): 建庫、修改表結構、設置約束等 - Mysql online DDL特性 : https://blog.csdn.net/finalkof1983/article/details/88355314 --- - 我們使用的`mutex`互斥鎖類似悲觀鎖，總是假設會有并發的操作要修改被操作的值，所以使用鎖將相關操作放入臨界區中加以保護。而使用`CAS`操作的做法趨于樂觀鎖，總是假設被操作值未曾被改變（即與舊值相等），并一旦確認這個假設的真實性就立即進行值替換。在被操作值被頻繁變更的情況下，`CAS`操作并不那么容易成功所以需要不斷進行嘗試，直到成功為止。 - 原子操作也有劣勢。還是以`CAS`操作為例，使用`CAS`操作的做法趨于樂觀，總是假設被操作值未曾被改變（即與舊值相等），并一旦確認這個假設的真實性就立即進行值替換，那么在被操作值被頻繁變更的情況下，`CAS`操作并不那么容易成功。而使用互斥鎖的做法則趨于悲觀，我們總假設會有并發的操作要修改被操作的值，并使用鎖將相關操作放入臨界區中加以保護。 --- > ### 相關閱讀 - [MySQL樂觀鎖電商庫存并發問題應用](https://www.jianshu.com/p/efe85c5b4d62) - [ORM鏈式操作-悲觀鎖 & 樂觀鎖](https://goframe.org/pages/viewpage.action?pageId=1114324)