Java 中的悲觀鎖和樂觀鎖的實現

http://blog.163.com/ainiyiwannian2046@126/blog/static/4910134020093221132298/

鎖（locking）

業務邏輯的實現過程中，往往需要保證資料訪問的排他性。如在金融系統的日終結算

處理中，我們希望針對某個cut-off時間點的資料進行處理，而不希望在結算進行過程中

（可能是幾秒種，也可能是幾個小時），資料再發生變化。此時，我們就需要通過一些機

制來保證這些資料在某個操作過程中不會被外界修改，這樣的機制，在這裡，也就是所謂

的“鎖”，即給我們選定的目標資料上鎖，使其無法被其他程式修改。

Hibernate支援兩種鎖機制：即通常所說的“悲觀鎖（Pessimistic Locking）”

和“樂觀鎖（Optimistic Locking）”。

悲觀鎖（Pessimistic Locking）

悲觀鎖，正如其名，它指的是對資料被外界（包括本系統當前的其他事務，以及來自

外部系統的事務處理）修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定

狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能

真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系

統不會修改資料）。

一個典型的倚賴資料庫的悲觀鎖呼叫：

select * from account where name=”Erica” for update

這條sql 語句鎖定了account 表中所有符合檢索條件（name=”Erica”）的記錄。

本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。

Hibernate的悲觀鎖，也是基於資料庫的鎖機制實現。

下面的程式碼實現了對查詢記錄的加鎖：

 

String hqlStr =

"from TUser as user where user.name='Erica'";

Query query = session.createQuery(hqlStr);

query.setLockMode("user",LockMode.UPGRADE); //加鎖

List userList = query.list();//執行查詢，獲取資料

query.setLockMode對查詢語句中，特定別名所對應的記錄進行加鎖（我們為

TUser類指定了一個別名“user”），這裡也就是對返回的所有user記錄進行加鎖。

觀察執行期Hibernate生成的SQL語句：

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id

as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex

from t_user tuser0_ where (tuser0_.name='Erica' ) for update

這裡Hibernate通過使用資料庫的for update子句實現了悲觀鎖機制。

Hibernate的加鎖模式有：

Ø LockMode.NONE ： 無鎖機制。

Ø LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動

獲取。

Ø LockMode.READ ： Hibernate在讀取記錄的時候會自動獲取。

以上這三種鎖機制一般由Hibernate內部使用，如Hibernate為了保證Update

過程中物件不會被外界修改，會在save方法實現中自動為目標物件加上WRITE鎖。

Ø LockMode.UPGRADE ：利用資料庫的for update子句加鎖。

Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定實現，利用Oracle的for

update nowait子句實現加鎖。

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

Criteria.setLockMode

Query.setLockMode

Session.lock

注意，只有在查詢開始之前（也就是Hiberate 生成SQL 之前）設定加鎖，才會

真正通過資料庫的鎖機制進行加鎖處理，否則，資料已經通過不包含for update

子句的Select SQL載入進來，所謂資料庫加鎖也就無從談起。

樂觀鎖（Optimistic Locking）

相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依

靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是資料庫

效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

如一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進

行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過

程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作

員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾

百上千個併發，這樣的情況將導致怎樣的後果。

樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本

（Version）記錄機制實現。何謂資料版本？即為資料增加一個版本標識，在基於

資料庫表的版本解決方案中，一般是通過為資料庫表增加一個“version”欄位來

實現。

讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提

交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料

版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。

對於上面修改使用者帳戶資訊的例子而言，假設資料庫中帳戶資訊表中有一個

version欄位，當前值為1；而當前帳戶餘額欄位（balance）為$100。

1 操作員A 此時將其讀出（version=1），並從其帳戶餘額中扣除$50

（$100-$50）。

2 在操作員A操作的過程中，操作員B也讀入此使用者資訊（version=1），並

從其帳戶餘額中扣除$20（$100-$20）。

3 操作員A完成了修改工作，將資料版本號加一（version=2），連同帳戶扣

除後餘額（balance=$50），提交至資料庫更新，此時由於提交資料版本大

於資料庫記錄當前版本，資料被更新，資料庫記錄version更新為2。

4 操作員B完成了操作，也將版本號加一（version=2）試圖向資料庫提交數

據（balance=$80），但此時比對資料庫記錄版本時發現，操作員B提交的

資料版本號為2，資料庫記錄當前版本也為2，不滿足“提交版本必須大於記

錄當前版本才能執行更新“的樂觀鎖策略，因此，操作員B 的提交被駁回。

這樣，就避免了操作員B 用基於version=1 的舊資料修改的結果覆蓋操作

員A的操作結果的可能。

從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員A

和操作員B操作過程中，都沒有對資料庫資料加鎖），大大提升了大併發量下的系

統整體效能表現。

需要注意的是，樂觀鎖機制往往基於系統中的資料儲存邏輯，因此也具備一定的局

限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的使用者

餘額更新操作不受我們系統的控制，因此可能會造成髒資料被更新到資料庫中。在

系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如

將樂觀鎖策略在資料庫儲存過程中實現，對外只開放基於此儲存過程的資料更新途

徑，而不是將資料庫表直接對外公開）。

Hibernate 在其資料訪問引擎中內建了樂觀鎖實現。如果不用考慮外部系統對數

據庫的更新操作，利用Hibernate提供的透明化樂觀鎖實現，將大大提升我們的

生產力。

Hibernate中可以通過class描述符的optimistic-lock屬性結合version

描述符指定。

現在，我們為之前示例中的TUser加上樂觀鎖機制。

1． 首先為TUser的class描述符新增optimistic-lock屬性：

<hibernate-mapping>

<class

name="org.hibernate.sample.TUser"

table="t_user"

dynamic-update="true"

dynamic-insert="true"

optimistic-lock="version"

>

……

</class>

</hibernate-mapping>

optimistic-lock屬性有如下可選取值：

Ø none

無樂觀鎖

Ø version

通過版本機制實現樂觀鎖

Ø dirty

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

Ø all

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

其中通過version實現的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現，同時也

是Hibernate中，目前唯一在資料物件脫離Session發生修改的情況下依然有效的鎖機

制。因此，一般情況下，我們都選擇version方式作為Hibernate樂觀鎖實現機制。

2． 新增一個Version屬性描述符

<hibernate-mapping>

<class

name="org.hibernate.sample.TUser"

table="t_user"

dynamic-update="true"

dynamic-insert="true"

optimistic-lock="version"

>

<id

name="id"

column="id"

type="java.lang.Integer"

>

<generator class="native">

</generator>

</id>

<version

column="version"

name="version"

type="java.lang.Integer"

/>

……

</class>

</hibernate-mapping>

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

這裡我們宣告瞭一個version屬性，用於存放使用者的版本資訊，儲存在TUser表的

version欄位中。

此時如果我們嘗試編寫一段程式碼，更新TUser表中記錄資料，如：

Criteria criteria = session.createCriteria(TUser.class);

criteria.add(Expression.eq("name","Erica"));

List userList = criteria.list();

TUser user =(TUser)userList.get(0);

Transaction tx = session.beginTransaction();

user.setUserType(1); //更新UserType欄位

tx.commit();

每次對TUser進行更新的時候，我們可以發現，資料庫中的version都在遞增。

而如果我們嘗試在tx.commit 之前，啟動另外一個Session，對名為Erica 的用

戶進行操作，以模擬併發更新時的情形：

Session session= getSession();

Criteria criteria = session.createCriteria(TUser.class);

criteria.add(Expression.eq("name","Erica"));

Session session2 = getSession();

Criteria criteria2 = session2.createCriteria(TUser.class);

criteria2.add(Expression.eq("name","Erica"));

List userList = criteria.list();

List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);

TUser user2 =(TUser)userList2.get(0);

Transaction tx = session.beginTransaction();

Transaction tx2 = session2.beginTransaction();

user2.setUserType(99);

tx2.commit();

user.setUserType(1);

tx.commit();

執行以上程式碼，程式碼將在tx.commit()處丟擲StaleObjectStateException異

常，並指出版本檢查失敗，當前事務正在試圖提交一個過期資料。通過捕捉這個異常，我

們就可以在樂觀鎖校驗失敗時進行相應處理。