樂觀鎖vs悲觀鎖

引言

爲何須要鎖（併發控制）

在併發的環境中，會存在多個用戶同時更新同一條數據，這時就會產生衝突。

衝突結果：

• 丟失更新：一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。
• 髒讀：當一個事務讀取其它完成一半事務的記錄時，就會發生髒讀取。

所以爲了解決上述問題，引入了併發控制機制。

樂觀鎖(樂觀併發控制)和悲觀鎖(悲觀併發控制)是併發控制的主要手段， 其實不只關係型數據庫中有樂觀鎖和悲觀鎖的概念，像redis，memcached等都有相似的概念。因此，不要把樂觀鎖和悲觀鎖狹隘的理解爲DBMS中的概念，更不能把他們和數據庫中提供的鎖機制混爲一談。其實，在DBMS中悲觀鎖正是利用了數據庫提供的鎖機制實現的。 

所以咱們針對不一樣的業務場景，應該選擇不一樣的併發控制方式。

1、悲觀鎖                                                                                                                         

悲觀鎖指的是外界對數據修改持保守態度(悲觀)，所以，在整個數據處理過程當中，將數據處於鎖定狀態。 悲觀鎖的實現，每每依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然，即便在本系統中實現了加鎖機制，也沒法保證外部系統不會修改數據）。 

DBMS悲觀鎖是阻止一個事務以影響其餘用戶的方式來修改數據。若是一個事務執行的操做 某行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。 

悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。 

   

數據庫中，悲觀鎖的流程： 

對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際須要決定。 若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會釋放鎖了。 其間若是有其餘對該記錄作修改或加排他鎖的操做，都會等待咱們解鎖或直接拋出異常。

   

使用悲觀鎖

要使用悲觀鎖，咱們必須關閉mysql數據庫的自動提交屬性，由於MySQL默認使用auto commit模式，也就是說，當你執行一個更新操做後，MySQL會馬上將結果進行提交。set autocommit=0; 

//0.開始事務 

begin;/begin work;/start transaction; (三者選一就能夠) 

//1.查詢出商品信息 

select status from t_goods where id=1 for update; 

//2.根據商品信息生成訂單 

insert into t_orders (id,goods_id) values (null,1); 

//3.修改商品status爲2 

update t_goods set status=2; 

//4.提交事務 

commit;/commit work;

   

上面的查詢語句中，咱們使用了select…for update的方式， 這樣就經過開啓排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id爲1的 那條數據就被咱們鎖定了，其它的事務必須等本次事務提交以後才能執行。這樣咱們能夠保證當前的數據不會被其它事務修改。

注意點  

咱們須要注意一些鎖的級別，MySQL InnoDB默認行級鎖。 行級鎖都是基於索引的，若是一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住。上面咱們使用select…for update會把數據給鎖住（id上有主鍵索引)，所以不會使用表級鎖。

若是查詢語句中有表關聯，只是用for update會鎖住全部表的相關記錄，建議使用for update of t.id。若是你不想讓你的事務等待其餘事務的鎖，能夠在for update 後加上 nowait，這樣當趕上衝突時數據庫會拋出異常。

優點劣勢

悲觀併發控制其實是"先取鎖再訪問"的保守策略，爲數據處理的安全提供了保證。可是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增長產生死鎖的機會；另外，在只讀型事務處理中因爲不會產生衝突，也不必使用鎖，這樣作只能增長系統負載；還有會下降了並行性，一個事務若是鎖定了某行數據，其餘事務就必須等待該事務處理完才能夠處理那行數。

   

2、樂觀鎖                                                                                                                        

相對悲觀鎖而言，樂觀鎖假設認爲數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。 

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。通常的實現樂觀鎖的方式就是記錄數據版本。

實現數據版本有兩種方式：

第一種是使用版本號version，

第二種是使用時間戳timestamp（時間戳精度）。 

數據版本,爲數據增長的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當咱們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，若是數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，不然認爲是過時數據。 

DBMS會假設多用戶併發的事務在處理時不會彼此互相影響，各事務可以在不產生鎖的狀況下處理各自影響的那部分數據。在提交數據更新以前，每一個事務會先檢查在該事務讀取數據後，有沒有其餘事務又修改了該數據（修改該數據的事務已提交，或未提交；事務未提交會帶來數據丟失）。若是其餘事務有更新的話，正在提交的事務會進行回滾。

注：對於以上兩種方式,Hibernate自帶實現方式：在使用樂觀鎖的字段前加annotation: @Version, Hibernate在更新時自動校驗該字段。

使用版本號實現樂觀鎖

使用版本號時，能夠在數據初始化時指定一個版本號，每次對數據的更新操做都對版本號執行+1操做。並判斷當前版本號是否是該數據的最新的版本號。 

//1.查詢出商品信息 

select status,version from t_goods where id=#{id} 

//2.根據商品信息生成訂單 

//3.修改商品status爲2 

update t_goods 

set status=2,version=version+1 

where id=#{id} and version=#{version};

 

注意第二個事務執行update時，第一個事務已經提交了，因此第二個事務可以讀取到第一個事務修改的version。

下面這種極端的狀況：

咱們知道MySQL數據庫引擎InnoDB，事務的隔離級別是Repeatable Read，所以是不會出現髒讀、不可重複讀。

在這種極端狀況下，第二個事務的update因爲不能讀取第一個事務未提交的數據（第一個事務已經對這一條數據加了排他鎖，第二個事務須要等待獲取鎖），第二個事務獲取了排他鎖後，會發現version已經發生了改變從而提交失敗。  

優點劣勢

樂觀併發控制相信事務之間的數據競爭(datarace)的機率是比較小的， 所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。

樂觀鎖雖然沒有依賴數據庫提供的鎖機制，也能夠保證數據一致性。