樂觀鎖（ optimistic locking ） 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式：
1、使用版本號實現樂觀鎖
版本號的實現方式有兩種，乙個是資料版本機制，乙個是時間戳機制。具體如下。
a.使用資料版本（version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂資料版本？即為資料增加乙個版本標識，一般是通過為資料庫表增加乙個數字型別的 「version」 欄位來實現。當讀取資料時，將version欄位的值一同讀出，資料每更新一次，對此version值加一。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的version值進行比對，如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料。用下面的一張圖來說明：
某銀行兩工作人員同時操作同一賬戶。
比如a、b操作員同時讀取一餘額為1000元的賬戶，a操作員為該賬戶增加100元，b操作員同時為該賬戶扣除50元，a先提交，b後提交。最後實際賬戶餘額為1000-50=950元，但本該為1000+100-50=1050。這就是典型的併發問題。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本(version)記錄機制實現。何謂資料版本？即為資料增加乙個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加乙個 「version」 欄位來實現。
讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。
對於上面修改使用者帳戶資訊的例子而言，假設資料庫中帳戶資訊表中有乙個version欄位，當前值為1；而當前帳戶餘額字段(balance)為1000元。假設操作員a先更新完，操作員b後更新。
a、操作員a此時將其讀出(version=1)，並從其帳戶餘額中增加100(1000+100=1100)。
b、在操作員a操作的過程中，操作員b也讀入此使用者資訊(version=1)，並從其帳戶餘額中扣除50(1000-50=950)。
c、操作員a完成了修改工作，將資料版本號加一(version=2)，連同帳戶增加後餘額(balance=1100)，提交至資料庫更新，此時由於提交資料版本大於資料庫記錄當前版本，資料被更新，資料庫記錄version更新為2。
d、操作員b完成了操作，也將版本號加一(version=2)試圖向資料庫提交資料(balance=950)，但此時比對資料庫記錄版本時發現，操作員b提交的資料版本號為2，資料庫記錄當前版本也為2，不滿足 「提交版本必須大於記錄當前版本才能執行更新 「的樂觀鎖策略，因此，操作員b的提交被駁回。
這樣，就避免了操作員b用基於version=1的舊資料修改的結果覆蓋操作員a的操作結果的可能。
mysql樂觀鎖解決併發問題
部落格1 根本決解辦法只有乙個 佇列，別的說的沒有用 部落格2 1 使用版本號實現樂觀鎖 版本號的實現方式有兩種，乙個是資料版本機制，乙個是時間戳機制。具體如下。下單操作包括3步驟 1.查詢出商品資訊 select status,status,version from t goods where i...
樂觀鎖解決併發問題
為什麼需要鎖 在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 丟失更新 乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如 使用者a把值從6改為2，使用者b把值從2改為6，則使用者a丟失了他的更新。髒讀 當乙個事務讀取其...
樂觀鎖與悲觀鎖 解決併發問題
引言 為什麼需要鎖 併發控制 在多使用者環境 中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 為了解決這些併發帶來的問題。我們需要引入併發控制機制。悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。1 樂觀鎖 假設不會發生併發衝突，只在...