（一）樂觀鎖和悲觀鎖的概念
悲觀鎖
在關系數據庫管理系統里，悲觀並發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種並發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作。
悲觀並發控制主要用於數據爭用激烈的環境，以及發生並發沖突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。
悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，因此，在整個數據處理過程中，將數據處於鎖定狀態。 悲觀鎖的實現，往往依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）
在數據庫中，悲觀鎖的流程如下：
在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。
如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。
如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。
其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。
優點與不足
悲觀並發控制實際上是“先取鎖再訪問”的保守策略，為數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生沖突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完才可以處理那行數
樂觀鎖
在關系數據庫管理系統里，樂觀並發控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種並發控制的方法。它假設多用戶並發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。
樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。
數據版本,為數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期數據。
實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。
優點與不足
樂觀並發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題。
（二）實例說明
假如兩個線程同時修改數據庫同一條記錄，就會導致后一條記錄覆蓋前一條，從而引發一些問題。
舉個典型電商例子例如：
一個電商平台，某個時間做秒殺活動或者促銷活動，客戶端每下單一個並付款成功庫存減一
情景：
來個極端點的情況，現在庫存只剩1個，假設兩個用戶同一時刻進行下單（並發），它們做的操作都是先查詢庫存數，然后減一。
一般的sql語句：
declare @count as int
begin TRAN
select @count=total from TbTicket WHERE GoodID ='001'
WAITFOR DELAY '00:00:05' --模擬並發，故意延遲5秒
IF(@count >= 1)
begin
update TbTicket set total=@count-1,CountNum=CountNum+1 ,updatedate=GETDATE() WHERE GoodID ='001'
end
commit TRAN
看上去好像沒啥問題，邏輯也很正確，但是如果並發來了，會出現什么情況？
同一時間獲取的庫存都為1，每個用戶都做了一次更新為0的操作，導致數據庫庫存少了1個，而實際出庫出了2個。
打開兩個查詢窗口，分別快速運行以上代碼即可看到效果（CountNum這個的目的就是為了明確知道執行了幾次，按照上面的程序CountNum會變成2，修改兩次數據，因為進到程序獲取庫存的時候都會獲得到庫存為1）。
那接下來就可以用到我們上面提到的悲觀鎖和樂觀鎖，怎么處理呢?
悲觀鎖處理方式：
在查詢的時候加了一個更新鎖，保證自查詢起直到事務結束不會被其他事務讀取修改，避免產生臟數據。
declare @count as int
begin TRAN
select @count=total from TbTicket WITH(UPDLOCK) WHERE GoodID ='001'
WAITFOR DELAY '00:00:05' --模擬並發，故意延遲5秒
IF(@count>= 1)
begin
update TbTicket set total=@count-1,CountNum=CountNum+1 ,updatedate=GETDATE() WHERE GoodID ='001'
end
commit TRAN
很明顯的可以發現，和上面的腳本對比其實就是加了一個 WITH(UPDLOCK)，但是區別就很明顯。我們將上面兩個未做任何加鎖的腳本上面加上WITH(UPDLOCK)，再短時間內一起執行，看下會不會執行兩次，CountNum會不會變成2？會不會還是出現數據庫庫存減1，而實際要出庫2個
樂觀鎖處理方式：
樂觀鎖常用方式就是加版本號和時間戳，我們接下來就用時間戳的方式來來說明。
首先在數據表中加入一列timestamp，附帶的說一下這個類型有點類似數據庫自增列的二進制類型，每次對數據操做都會修改此數據，數據結構如下：
declare @count as int
DECLARE @flag AS TIMESTAMP
DECLARE @rowCount AS int
declare @d datetime
set @d=getdate()
begin tran
select @count=total,@flag=timesflag from TbTicket WHERE GoodID ='001'
WAITFOR DELAY '00:00:05'
update TbTicket set total=@count-1,CountNum=CountNum+1 ,updatedate=GETDATE() WHERE GoodID ='001' AND timesflag=@flag --這里加了條件
SET @rowcount=@@ROWCOUNT --獲取被修改的行數
commit TRAN
--對行數進行判斷即可
IF @rowCount=1
PRINT '更新成功'
ELSE
PRINT '更新失敗'
select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())
同樣可以按照上面的操做執行下腳本，看下效果，最后一行其實就是想看下執行腳本的耗費的具體時間，想和悲觀鎖進行對比下效率，以上僅供參考，歡迎朋友們一起來討論和學習。
（三）總結
悲觀鎖一定成功，但在並發量特別大的時候會造成很長堵塞甚至超時，僅適合小並發的情況。
樂觀鎖不一定每次都修改成功，但能充分利用系統的並發處理機制，在大並發量的時候效率要高很多。