在數據庫的鎖機制中介紹過，數據庫管理系統（DBMS）中的并發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。

樂觀并發控制(樂觀鎖)和悲觀并發控制（悲觀鎖）是并發控制主要采用的技術手段。

無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。其實不僅僅是關系型數據庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。

針對于不同的業務場景，應該選用不同的并發控制方式。所以，不要把樂觀并發控制和悲觀并發控制狹義的理解為DBMS中的概念，更不要把他們和數據中提供的鎖機制（行鎖、表鎖、排他鎖、共享鎖）混為一談。其實，在DBMS中，悲觀鎖正是利用數據庫本身提供的鎖機制來實現的,也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據。

下面來分別學習一下悲觀鎖和樂觀鎖。

一、悲觀鎖

在關系數據庫管理系統里，悲觀并發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種并發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作。

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

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，因此，在整個數據處理過程中，將數據處于鎖定狀態。 悲觀鎖的實現，往往依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）*

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

在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。

如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。

如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。

1、MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，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的 那條數據就被我們鎖定了，其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。

上面我們提到，使用select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基于索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。

2、hibernate實現悲觀鎖

hibernate的悲觀鎖也是基于數據庫的鎖機制實現的。下面的代碼實現了對查詢記錄加鎖：

String hqlStr = "from TUser as user where user.name='Tom'"; Query query = session.createQuery(hqlStr); query.setLockMode("user",LockMode.UPGRADE);//加鎖 List userList = query.list();//執行查詢，獲取數據

query.setLockMode()方法對查詢語句中特定別名對應的記錄進行加鎖（我們為TUser類指定了一個別名user），這里也就是對返回的user記錄進行加鎖。

select tuser_id as id,tuser_name as name,tuser_group as group from t_user tuser where tuser_name='Tom' for update;

這里hibernate通過使用數據庫的for update子句實現了悲觀鎖機制。

hibernate的加鎖模式有：

1、LockMode：NONE：無鎖機制

2、LockMode.WRITE：hibernate在insert和update記錄的時候會自動獲取

3、LockMode.READ：hibernate在讀取記錄的時候或自動獲取

以上三種鎖機制一般由hibernate內部使用，如hibernate為了保證update過程中對象不會被外界修改，會在save方法實現中自動為目標對象加上WRITE鎖。

4、LockMode.UPGRADE：利用數據庫的for update子句加鎖

5、LockMode.UPGRADE_NOWAIT：Oracle的特定實現，利用Oracle的for update nowait子句實現加鎖。

上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現：

Criteria.setLockMode

Query.setLockMode

Session.lock

注意：只有在查詢開始之前（也就是hibernate生成SQL之前）設定加鎖，才會真正通過數據庫的鎖機制進行加鎖處理。否則，數據已經通過不包含for update的子句select sql加載進來了，所謂數據庫加鎖也就無從談起。另外，for update要放到MySQL的事務中，即begin和commit中，否則不起作用。

至于是鎖住整個表還是鎖住選中的行，參考：

MySQL中select * for update鎖表的問題

由于InnoDB預設是Row-Level Lock，所以只有「明確」的指定主鍵，MySQL才會執行Row lock (只鎖住被選取的資料例) ，否則MySQL將會執行Table

Lock (將整個資料表單給鎖住)。 舉個例子: 假設有個表單products ，里面有id跟name二個欄位，id是主鍵。

例1: (明確指定主鍵，并且有此筆資料，row lock)

SELECT * FROM products WHERE id=’3’ FOR UPDATE;

SELECT * FROM products WHERE id=’3’ and type=1 FOR UPDATE;

例2: (明確指定主鍵，若查無此筆資料，無lock)

SELECT * FROM products WHERE id=’-1’ FOR UPDATE;

例2: (無主鍵，table lock)

SELECT * FROM products WHERE name=’Mouse’ FOR UPDATE;

例3: (主鍵不明確，table lock)

SELECT * FROM products WHERE id<>’3’ FOR UPDATE;

例4: (主鍵不明確，table lock)

SELECT * FROM products WHERE id LIKE ‘3’ FOR UPDATE;

注1: FOR UPDATE僅適用于InnoDB，且必須在交易區塊(BEGIN/COMMIT)中才能生效。

注2: 要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。在MySql 5.0中測試確實是這樣的。

另外：MyAsim 只支持表級鎖，InnerDB支持行級鎖 添加了(行級鎖/表級鎖)鎖的數據不能被其它事務再鎖定，也不被其它事務修改（修改、刪除） 。是表級鎖時，不管是否查詢到記錄，都會鎖定表。

3、優點與不足

悲觀并發控制實際上是“先取鎖再訪問”的保守策略，為數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由于不會產生沖突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了并行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完才可以處理那行數

二、樂觀鎖

在關系數據庫管理系統里，樂觀并發控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種并發控制的方法。它假設多用戶并發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。

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

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

實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

1、使用版本號實現樂觀鎖

使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。并判斷當前版本號是不是該數據的最新的版本號。

查詢出商品信息

select (status,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};

需要注意的是，樂觀鎖機制往往基于系統中數據存儲邏輯，因此也具備一定的局限性。由于樂觀鎖機制是在我們的系統中實現的，對于來自外部系統的用戶數據更新操作不受我們系統的控制，因此可能會造成臟數據被更新到數據庫中。在系統設計階段，我們應該充分考慮到這些情況，并進行相應的調整（如將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基于此存儲過程的數據更新途徑，而不是將數據庫表直接對外公開）。

hibernate在其數據訪問引擎中內置了樂觀鎖的實現。如果不用考慮外部系統對數據庫的更新操作，利用hibernate提供的透明化樂觀鎖實現，將大大提升我們的效率。

User.hbm.xml：

<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC"-//Hibernate/Hibernate Mapping DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"><hibernate-mapping package="com.xiaohao.test"><class name="User" table="user" optimistic-lock="version" ><id name="id"><generator class="native" /></id><!--version標簽必須跟在id標簽后面--><version column="version" name="version" /><property name="userName"/><property name="password"/></class> </hibernate-mapping>

注意：version節點必須出現在ID節點之后。

這里我們聲明了一個version屬性，用于存放用戶的版本信息，保存在User表的version中，optimistic-lock屬性有如下可選取值：

1、none 無樂觀鎖

2、version 通過版本機制實現樂觀鎖

3、dirty 通過檢查發生變動過的屬性實現樂觀鎖

4、all 通過檢查所有屬性實現樂觀鎖

其中通過version實現的樂觀鎖機制是hibernate官方推薦的樂觀鎖實現，同時也是hibernate中，目前唯一一種在數據對象脫離session發生修改的情況下依然有效的鎖機制。因此，一般情況下，我們都選擇version方式作為hibernate樂觀鎖的實現機制。

2、優點與不足

樂觀并發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題。

三、總結

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似于write_condition機制的其實都是提供的樂觀鎖。

兩種鎖各有優缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生沖突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。

總結

以上是生活随笔為你收集整理的乐观锁与悲观锁深入学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。