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

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" ynamic-insert="true" optimistic-lock="version">
……
</class>
</hibernate-mapping>

optimistic-lock屬性有如下可選取值：
Ø 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異常，並指出版本檢查失敗，當前事務正在試圖提交一個過期資料。通過捕捉這個異常，我們就可以在樂觀鎖校驗失敗時進行相應處理。