在阿里巴巴近期發出的阿里巴巴JAVA開發手冊（終極版）中有這樣一條記錄。

【強制】併發修改同一記錄時，避免更新丟失，需要加鎖。要麼在應用層加鎖，要麼在快取加鎖，要麼在資料庫層使用樂觀鎖，使用version作為更新依據。

說明：如果每次訪問衝突概率小於20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數不得小於3次。

那麼什麼是樂觀鎖呢？

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式：

通過例項讓大家詳細理解

銀行兩操作員同時操作同一賬戶就是典型的例子。
比如A、B操作員同時讀取一餘額為1000元的賬戶，A操作員為該賬戶增加100元，B操作員同時為該賬戶扣除50元，A先提交，B後提交。最後實際賬戶餘額為1000-50=950元，但本該為1000+100-50=1050。這就是典型的併發問題。

對於上面修改使用者帳戶資訊的例子而言，假設資料庫中帳戶資訊表中有一個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的操作結果的可能。

資料建表

t_goods表，增加一個version欄位，資料預設version值為0。

t_goods表初始資料如下：

1. mysql> select * from t_goods;  
2. +----+--------+------+---------+
3. | id | status | name | version |  
4. +----+--------+------+---------+
5. |  1 |      1 | 道具 |       0 |  
6. |  2 |      2 | 裝備 |       1 |  
7. +----+--------+------+---------+
8. 2 rowsinset

mybatis實現

Goods實體類：

1. /** 
2.  * ClassName: Goods <br/> 
3.  * Function: 商品實體. <br/> 
4.  * date: 2013-5-8 上午09:16:19 <br/> 
5.  * @author [email protected] 
6.  */
7. publicclass Goods implements Serializable {  
8.     /** 
9.      * serialVersionUID:序列化ID. 
10.      */
11.     privatestaticfinallong serialVersionUID = 6803791908148880587L;  
12.     /** 
13.      * id:主鍵id. 
14.      */
15.     privateint id;  
16.     /** 
17.      * status:商品狀態：1未下單、2已下單. 
18.      */
19.     privateint status;  
20.     /** 
21.      * name:商品名稱. 
22.      */
23.     private String name;  
24.     /** 
25.      * version:商品資料版本號. 
26.      */
27.     privateint version;  
28.     @Override
29.     public String toString(){  
30.         return"good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version;  
31.     }  
32.     //setter and getter
33. }  

GoodsDao

1. /** 
2.  * updateGoodsUseCAS:使用CAS(Compare and set)更新商品資訊. <br/> 
3.  * 
4.  * @author [email protected] 
5.  * @param goods 商品物件 
6.  * @return 影響的行數 
7.  */
8. int updateGoodsUseCAS(Goods goods);  

mapper.xml

1. <updateid="updateGoodsUseCAS"parameterType="Goods">
2.     <![CDATA[ 
3.         update t_goods 
4.         set status=#{status},name=#{name},version=version+1 
5.         where id=#{id} and version=#{version} 
6.     ]]>
7. </update>

GoodsDaoTest測試類

1. @Test
2. publicvoid goodsDaoTest(){  
3.     int goodsId = 1;  
4.     //根據相同的id查詢出商品資訊，賦給2個物件
5.     Goods goods1 = this.goodsDao.getGoodsById(goodsId);  
6.     Goods goods2 = this.goodsDao.getGoodsById(goodsId);  
7.     //列印當前商品資訊
8.     System.out.println(goods1);  
9.     System.out.println(goods2);  
10.     //更新商品資訊1
11.     goods1.setStatus(2);//修改status為2
12.     int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1);  
13.     System.out.println("修改商品資訊1"+(updateResult1==1?"成功":"失敗"));  
14.     //更新商品資訊2
15.     goods1.setStatus(2);//修改status為2
16.     int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods1);  
17.     System.out.println("修改商品資訊2"+(updateResult2==1?"成功":"失敗"));  
18. }  

輸出結果：

1. good id:1,goods status:1,goods name:道具,goods version:1
2. good id:1,goods status:1,goods name:道具,goods version:1
3. 修改商品資訊1成功  
4. 修改商品資訊2失敗  

說明：

在GoodsDaoTest測試方法中，我們同時查出同一個版本的資料，賦給不同的goods物件，然後先修改good1物件然後執行更新操作，執行成功。然後我們修改goods2，執行更新操作時提示操作失敗。此時t_goods表中資料如下：

1. mysql> select * from t_goods;  
2. +----+--------+------+---------+
3. | id | status | name | version |  
4. +----+--------+------+---------+
5. |  1 |      2 | 道具 |       2 |  
6. |  2 |      2 | 裝備 |       2 |  
7. +----+--------+------+---------+
8. 2 rowsinset
9. mysql>   

我們可以看到 id為1的資料version已經在第一次更新時修改為2了。所以我們更新good2時update where條件已經不匹配了，所以更新不會成功，具體sql如下：

1. update t_goods   
2. set status=2,version=version+1  
3. where id=#{id} and version=#{version};  

這樣我們就在Mybatis實現了樂觀鎖

持久層使用jpa時比較簡單，JPA預設提供了一個註解@Version，我們只需要在剛才的實體類中做相應的註解就可以。

Goods實體類：

1. /** 
2.  * ClassName: Goods <br/> 
3.  * Function: 商品實體. <br/> 
4.  * date: 2013-5-8 上午09:16:19 <br/> 
5.  * @author [email protected] 
6.  */
7. publicclass Goods implements Serializable {  
8.     /** 
9.      * serialVersionUID:序列化ID. 
10.      */
11.     privatestaticfinallong serialVersionUID = 6803791908148880587L;  
12.     /** 
13.      * id:主鍵id. 
14.      */

15.     @Id
        @GenericGenerator(name = "PKUUID", strategy = "uuid2")
        @GeneratedValue(generator = "PKUUID")
        @Column(length = 36)

16.     privateInteger id;  
17.     /** 
18.      * status:商品狀態：1未下單、2已下單. 
19.      */

20.   @Column(name = "status") 

21.     private Integer status;  
22.     /** 
23.      * name:商品名稱. 
24.      */

25.   @Column(name = "name")

26.     private String name;  
27.     /** 
28.      * version:商品資料版本號. 
29.      */

30.   @Version 

31.     privateInteger version;  
32.     @Override
33.     public String toString(){  
34.         return"good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version;  
35.     }  
36.     //setter and getter
37. }  

總結

樂觀鎖，用在一些敏感業務資料上，而其本身的修飾：樂觀，代表的含義便是相信大多數場景下version是一致的。但是從業務角度出發又要保證資料的嚴格一致性，避免髒讀等問題，使用的場景需要斟酌。記得前面一片博文簡單介紹了一下行級鎖的概念，其實本質上和樂觀鎖都是想要再資料庫層面加鎖控制併發，那麼什麼時候該用樂觀鎖，行級鎖，什麼時候得在程式級別加同步鎖，又要根據具體的業務場景去判斷。找到能夠滿足自己專案需求的方案，找到效能和可靠性的平衡點，才是一個程式設計師的價值所在。

歡迎大家關注、轉載、評論。

大家有什麼問題需要討論的也歡迎在評論下留言，我會隨時關注，大家一起進步。

參考部落格地址：

http://www.cnblogs.com/linjiqin/p/5096206.html

http://chenzhou123520.iteye.com/blog/1863407

http://blog.csdn.net/u013815546/article/details/54784025

http://blog.csdn.net/tzdwsy/article/details/47976919