百上千個併發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本
（ version ）記錄機制實現。何謂資料版本？即為資料增加乙個版本標識，在基於
資料庫表的版本解決方案中，一般是通過為資料庫表增加乙個 「version」 欄位來
實現。
讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提
交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料
版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。
對於上面修改使用者帳戶資訊的例子而言，假設資料庫中帳戶資訊表中有乙個
version 字段，當前值為 1 ；而當前帳戶餘額字段（ balance ）為 $100 。
1 操作員 a 此時將其讀出（ version=1 ），並從其帳戶餘額中扣除 $50
（ $100-$50 ）。
2 在操作員 a 操作的過程中，操作員 b 也讀入此使用者資訊（ version=1 ），並
從其帳戶餘額中扣除 $20 （ $100-$20 ）。
3 操作員 a 完成了修改工作，將資料版本號加一（ version=2 ），連同帳戶扣
除后餘額（ balance=$50 ），提交至資料庫更新，此時由於提交資料版本大
於資料庫記錄當前版本，資料被更新，資料庫記錄 version 更新為 2 。
4 操作員 b 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交數
據（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 b 提交的
資料版本號為 2 ，資料庫記錄當前版本(
再查一遍該記錄
)也為 2 ，不滿足 「 提交版本必須大於記
錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 b 的提交被駁回。
這樣，就避免了操作員 b 用基於 version=1 的舊資料修改的結果覆蓋操作
員 a 的操作結果的可能。
從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員 a
和操作員 b 操作過程中，都沒有對資料庫資料加鎖），大大提公升了大併發量下的系
統整體效能表現。
需要注意的是，樂觀鎖機制往往基於系統中的資料儲存邏輯，因此也具備一定的局
限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的使用者
餘額更新操作不受我們系統的控制，因此可能會造成髒資料被更新到資料庫中。在
系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如
將樂觀鎖策略在資料庫儲存過程中實現，對外只開放基於此儲存過程的資料更新途
徑，而不是將資料庫表直接對外公開）。
資料庫樂觀鎖
兩個執行緒同時運算元據庫時，希望可以實現，乙個執行緒在修改資料庫的時候，另外乙個執行緒不能對同一條資料進行修改。sql語句 update money set money money 1,version version 1where id and version 測試類 executorservice...
資料庫樂觀鎖
樂觀鎖不是資料庫自帶的，需要我們自己去實現。樂觀鎖是指運算元據庫時 更新操作 想法很樂觀，認為這次的操作不會導致衝突 a使用者操作的時，沒有任何人操作該條記錄 在運算元據時，並不進行任何其他的特殊處理 也就是不加鎖 而在進行更新後，再去判斷是否有衝突了。通常實現是這樣的 在表中的資料進行操作時 更新...
資料庫樂觀鎖
簡單來說就是增加乙個字段 version 用來記錄更新的版本，更新前先查詢版本 然後進行更新操作時判斷版本是否等於上一步查詢的版本，如果是則成功 並且將版本公升級 1 select stock,version from table store 查詢出當前版本 如查詢的version字段值為2，則更新...