樂觀鎖，大多是基于數(shù)據(jù)版本?? Version )記錄機制實現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是通

過為數(shù)據(jù)庫表增加一個 “version” 字段來?實現(xiàn)。?讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提?交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)

庫表對應(yīng)記錄的當前版本信息進行比對，如果提交的數(shù)據(jù)?版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。對于上面修改用戶帳戶信息

的例子而言，假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個?version 字段，當前值為 1 ；而當前帳戶余額字段( balance )為 $100 。操作員 A 此時將其讀出

( version=1 )，并從其帳戶余額中扣除 $50( $100-$50 )。?2 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息( version=1 )，并?從其帳

戶余額中扣除 $20 ( $100-$20 )。?3 操作員 A 完成了修改工作，將數(shù)據(jù)版本號加一( version=2 )，連同帳戶扣?除后余額( balance=$50 )，提交

至數(shù)據(jù)庫更新，此時由于提交數(shù)據(jù)版本大?于數(shù)據(jù)庫記錄當前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄 version 更新為 2 。?4 操作員 B 完成了操作，也將版本號加一

( version=2 )試圖向數(shù)據(jù)庫提交數(shù)?據(jù)( balance=$80 )，但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)，操作員 B 提交的?數(shù)據(jù)版本號為 2 ，數(shù)據(jù)庫記錄當前版

本也為 2 ，不滿足 “ 提交版本必須大于記?錄當前版本才能執(zhí)行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。?這樣，就避免了操作員 B 用基于

version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作?員 A 的操作結(jié)果的可能。?從上面的例子可以看出，樂觀鎖機制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷(操作員 A

和操作員 B 操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖)，大大提升了大并發(fā)量下的系?統(tǒng)整體性能表現(xiàn)。?需要注意的是，樂觀鎖機制往往基于系統(tǒng)中的數(shù)據(jù)存儲

邏輯，因此也具備一定的局?限性，如在上例中，由于樂觀鎖機制是在我們的系統(tǒng)中實現(xiàn)，來自外部系統(tǒng)的用戶?余額更新操作不受我們系統(tǒng)的控制，因此可能

會造成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。在?系統(tǒng)設(shè)計階段，我們應(yīng)該充分考慮到這些情況出現(xiàn)的可能性，并進行相應(yīng)調(diào)整(如?將樂觀鎖策略在數(shù)據(jù)庫存儲過程中實

現(xiàn)，對外只開放基于此存儲過程的數(shù)據(jù)更新途?徑，而不是將數(shù)據(jù)庫表直接對外公開)。

總結(jié)

以上是生活随笔為你收集整理的java mysql乐观锁_java乐观锁使用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。