悲觀鎖資料庫的mvcc機制就是這種，mvcc更加嚴格一點，後邊增加了建立版本及刪除版本兩個字段。
詳情參考：
版本號機制也是cas操作的一種，先比較再替換。
比如我有乙個學生表，有兩個字段，飯卡餘額和版本，初始化為，飯卡餘額為100，版本為1。
1、執行緒a吃飯刷了20塊錢，修改餘額為80，首先進行讀操作，記錄學生此時餘額為100，版本號為1。
2、執行緒b吃飯刷了40塊錢，修改餘額為60，首先進行讀操作，記錄學生此時餘額為100，版本號為1。
3、執行緒a要提交了，提交的版本為1+1=2，再次讀，看一下最新的資料，提交版本》當前版本1，可以提交，提交成功。
4、執行緒b要提交了，提交的版本為1+1=2，再次讀，看一下最新的資料，提交版本為2，當前版本為2，不滿足【提交版本》當前版本】前提條件，提交失敗。
（這裡直接比對版本號，也可以，如果版本號和自己記錄的版本號不一致，說明有人動過了，就不提交）
（這兩種比較方式，都是判斷一下有沒有其他執行緒對資料進行了更改）
執行緒a與執行緒b是有先後順序的，執行緒a更新執行後，執行緒b再執行， 這個時候執行緒b應該使用最新的資料，而不是使用版本1的舊資料。
你要提交的資料，版本號是要大於當前版本的。如果小於等於當前最新版本，說明已經有其他執行緒修改過了。
簡而言之，讀讀寫。
第一次讀，記錄資料。
第二次讀，比對資料。
開始寫。
compare and swap，無鎖演算法，非阻塞式同步。
cas演算法涉及三個運算元。
當且僅當a與v相等時，cas通過原子方式用新值b更新v。
我們最經常使用的鎖，比如下邊這兩個都是悲觀鎖，悲觀鎖加鎖，樂觀鎖不加鎖。
參考：
參考：
Hibernate鎖機制（悲觀鎖，樂觀鎖）
鎖 locking 業務邏輯的實現過程中，往往需要保證資料訪問的排他性。如在金融系統的日終結算處理中，我們希望針對某個cut off時間點的資料進行處理，而不希望在結算進行過程中 可能是幾秒種，也可能是幾個小時 資料再發生變化。此時，我們就需要通過一些機制來保證這些資料在某個操作過程中不會被外界修改...
悲觀鎖和樂觀鎖機制
由於併發的存在，當多個執行緒同時對資料庫的同一資料進行刪改查操作時，資料可能會不準確，因此資料庫會有行級鎖的概念。資料庫的行級鎖就是採用一種獨佔的方式，只要當前有乙個執行緒操作這條資料，那麼其他執行緒對該資料只有查詢的能力，沒有修改的權利，因此行級鎖具有排他性，這樣保證了資料的一致性和安全性。資料庫...
Mysql鎖機制之 樂觀鎖和悲觀鎖
悲觀鎖 pessimistic lock 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。注 要使用悲觀鎖，我們必須關閉mysql資料庫的自動提交屬性，因為mysql預設使用autocommit模式，也就是說，...