引言
為什麼需要鎖（併發控制）？
在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。
典型的衝突有：
為了解決這些併發帶來的問題。 我們需要引入併發控制機制。
悲觀鎖：假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。[1]
樂觀鎖：假設不會發生併發衝突，只在提交操作時檢查是否違反資料完整性。[1] 樂觀鎖不能解決髒讀的問題。
樂觀鎖應用
樂觀鎖介紹：
樂觀鎖（ optimistic locking ） 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式：
如上圖所示，如果更新操作順序執行，則資料的版本（version）依次遞增，不會產生衝突。但是如果發生有不同的業務操作對同一版本的資料進行修改，那麼，先提交的操作（圖中b）會把資料version更新為2，當a在b之後提交更新時發現資料的version已經被修改了，那麼a的更新操作會失敗。
2.樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加乙個字段，名稱無所謂，字段型別使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則ok，否則就是版本衝突。
使用舉例：以mysql innodb為例
還是拿之前的例項來舉：商品goods表中有乙個欄位status，status為1代表商品未被下單，status為2代表商品已經被下單，那麼我們對某個商品下單時必須確保該商品status為1。假設商品的id為1。
下單操作包括3步驟：
1.查詢出商品資訊
select (status,status,version) from t_goods where id=#2.根據商品資訊生成訂單
3.修改商品status為2
update t_goods那麼為了使用樂觀鎖，我們首先修改t_goods表，增加乙個version欄位，資料預設version值為1。set status=2,version=version+1where id=# and version=#;
t_goods表初始資料如下：
對於樂觀鎖的實現，我使用mybatis來進行實踐，具體如下：
goods實體類：
/**goodsdao* classname: goods
* function: 商品實體.
*/public class goods implements serializable //setter and getter}
/**goodsdaotest測試類* updategoodsusecas:使用cas(compare and set)更新商品資訊
* @param goods 商品物件
* @return 影響的行數 */int updategoodsusecas(goods goods);
@testpublic void goodsdaotest()輸出結果：
good id:1,goods status:1,goods name:道具,goods version:1說明：在goodsdaotestgood id:1,goods status:1,goods name:道具,goods version:1
修改商品資訊1成功
修改商品資訊2失敗
測試方法中，我們同時查出同乙個版本的資料，賦給不同的
goods
物件，然後先修改
good1
物件然後執行更新操作，執行成功。然後我們修改
goods2
，執行更新操作時提示操作失敗。此時
t_goods
表中資料如下：
mysql> select * from t_goods;+----+--------+------+---------+| id | status | name | version |+----+--------+------+---------+| 1 | 2 | 道具 | 2 || 2 | 2 | 裝備 | 2 |+----+--------+------+---------+2 rows in setmysql>我們可以看到 id為1
的資料version
已經在第一次更新時修改為
2了。所以我們更新
good2
時update where
條件已經不匹配了，所以更新不會成功，具體
sql如下：
update t_goods這樣我們就實現了樂觀鎖set status=2,version=version+1where id=# and version=#;
需要使用資料庫的鎖機制，比如sql server 的tablockx（排它表鎖） 此選項被選中時，sql server 將在整個表上置排它鎖直至該命令或事務結束。這將防止其他程序讀取或修改表中的資料。
sqlserver中使用
begin tran
select top 1 @trainno=t_no
from train_ticket with (updlock) where s_flag=0
update train_ticket
set t_name=user,
t_time=getdate(),
s_flag=1
where t_no=@trainno
commit
我們在查詢的時候使用了with (updlock)選項,在查詢記錄的時候我們就對記錄加上了更新鎖,表示我們即將對此記錄進行更新. 注意更新鎖和共享鎖是不衝突的,也就是其他使用者還可以查詢此表的內容,但是和更新鎖和排它鎖是衝突的.所以其他的更新使用者就會阻塞.
在實際生產環境裡邊,如果併發量不大且不允許髒讀，可以使用悲觀鎖解決併發問題；但如果系統的併發非常大的話,悲觀鎖定會帶來非常大的效能問題,所以我們就要選擇樂觀鎖定的方法.
樂觀鎖與悲觀鎖 解決併發問題
引言 為什麼需要鎖 併發控制 在多使用者環境 中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 為了解決這些併發帶來的問題。我們需要引入併發控制機制。悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。1 樂觀鎖 假設不會發生併發衝突，只在...
樂觀鎖與悲觀鎖 解決併發問題
引言 為什麼需要鎖 併發控制 在多使用者環境 中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 為了解決這些併發帶來的問題。我們需要引入併發控制機制。悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。1 樂觀鎖 假設不會發生併發衝突，只在...
樂觀鎖與悲觀鎖 解決併發問題
引言 為什麼需要鎖 併發控制 在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 為了解決這些併發帶來的問題。我們需要引入併發控制機制。悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。1 樂觀鎖 假設不會發生併發衝突，只在提...